Tab bar toolbar items are enabled against the focused widget, not the owning tab

Bug Description:

A tab bar toolbar item can be greyed out on its own tab because a different editor group has the focus.

TabBarToolbarItem.isEnabled and isToggled take only the widget. For plugin commands they end up in PluginContributionHandler, which evaluates the enablement clause against the ambient context key service:

https://github.com/eclipse-theia/theia/blob/98d1a268f03bc1a6709b0fbf6842c54c2ee13ccb/packages/plugin-ext/src/main/browser/plugin-contribution-handler.ts#L536-L541

The ambient context describes whichever widget currently has the focus, not the tab whose toolbar is being drawn. So with two editor groups side by side, the item on group A reads group B's resource*, editorLangId and similar keys.

This is the same root cause as #8921, which covers the visibility side and is being fixed in #17978. That PR evaluates isVisible against a context overlay describing the widget that owns the toolbar. Enablement was left out because the value would have to travel through CommandRegistry.isEnabled, which passes ...args to the handler and has no place to put a matcher. Adding one touches every command in the application, so it did not belong in a bug fix.

Steps to Reproduce:

1. Install a plugin that contributes an editor/title command with an enablement clause that depends on the resource, for example enablement: "resourceExtname == .probe".
2. Open a.probe, then split the editor and open b.txt in the other group.
3. Focus the b.txt group.
4. The button on the a.probe tab bar is greyed out, even though its own resource satisfies the clause.

Additional Information

• Operating System: Linux
• Theia Version: master