### Description

When the active bar is a **third-party** bar plugin (a `kind: ["bar"]` plugin that is not first-party — e.g. a clone of `omarchy.bar`), any hosted **service-backed** bar widget (a plugin declaring both `service` and `bar-widget` kinds) can no longer reach **its own** plugin's live service. The widget stays stuck in its "not ready" state forever, even though the backing service is running and healthy.

The widget does everything correctly — it asks the bar for its service via `bar.shell.serviceFor(PLUGIN_ID)` — but under a third-party bar the shell handed to the bar is a *scoped* shell whose `serviceFor()` returns `null` for anything outside a small first-party allowlist. So the widget silently never becomes ready. There is no error in the logs.

### Steps to reproduce

1. Install/enable any plugin that declares `kinds: ["service", "bar-widget"]` (e.g. `oliwier.auto-pilot4agents`, or the built-in `omarchy.media` / a clone like `pablo.media`) and add its widget to the bar.
2. Switch the active bar to a third-party bar plugin: `omarchy bar use <third-party-bar-id>` (e.g. a clone of `omarchy.bar`).
3. Observe the widget: it remains in its "starting"/not-ready state indefinitely.
4. Switch back to the default first-party bar (`omarchy bar use omarchy.bar`): the widget becomes ready and works normally.

### Expected behavior

A bar widget should be able to reach **its own** plugin's service even when hosted by a third-party bar. The scoping boundary should prevent a widget from reaching **other** plugins' services, but not its own (`owns`-check).

### Actual behavior

`bar.shell.serviceFor(<own PLUGIN_ID>)` returns `null` under a third-party bar, so the widget is permanently non-functional. The backing service is confirmed healthy at the same time (its IPC `status()` reports `{"ready":true,...}`).

### Root cause (verified in shell source)

- `shell/shell.qml` `pluginShellFor(manifest)`: a first-party bar receives the full `shell` (whose `serviceFor()` resolves any plugin's service), but a third-party bar receives `createScopedPluginShell(...)`.
- In the scoped shell, the service lookups only expose a fixed first-party allowlist (`["omarchy.idle", "omarchy.media", "omarchy.nightlight", "omarchy.notifications"]`) and gate even those on `activeBarManifest.__isFirstParty`. The inline comment states the intent: *"not … access to another plugin's live service."*
- A hosted widget's own service is therefore unreachable, because the scoping treats "the widget's own service" the same as "another plugin's service."

### Impact

Third-party bars and service-backed widgets are mutually exclusive, silently. Users who run a custom bar (very common — auto-hiding bars, alternative layouts) lose all service-backed widgets with no visible error, and vice versa.

### Suggested fix

Allow a scoped bar's per-widget shell to resolve the widget's **own** plugin service (an `owns()`-style check keyed by the widget's plugin id), while keeping the existing block on reaching other plugins' services.

### System details

- Omarchy: 4.0.4-1
- Quickshell: 0.3.1 (Arch)
- Kernel: 7.2.5-3-omarchy