## What happened

A **bar widget** that owns a service cannot reach that service, so its bar button silently does nothing — but only when the bar in use is a **cloned / third-party bar** (`omarchy plugin clone omarchy.bar`). With the stock first-party bar the same plugin works.

Reproduced with [`omasettings`](https://github.com/twiking/omasettings) (`io.github.twiking.omasettings`, kinds `bar-widget` + `service`):

- Clicking the gear in the bar does nothing. No window, no error.
- `omarchy-shell omasettings show` opens the window fine.
- `hyprctl layers` confirms no `omasettings` layer is created by the click.

No QML error is logged, which is what makes it hard to diagnose.

## Root cause

A bar widget reaches its service through **`bar.shell`**, and `bar.shell` is the scope of the **bar plugin**, not the widget's:

- `configureBar()` injects the bar root's `shell` with `shell.pluginShellFor(manifest)` — where `manifest` is the **bar's** manifest (`shell.qml:221`).
- `pluginShellFor()` returns the **full host shell** only for first-party manifests; for anything else it returns a scoped `PluginShellApi` bound to the bar's own id (`shell.qml:739`).
- That scoped api resolves services through `pluginServiceFor(key, requestedId)`, which is gated by `pluginOwnsTarget(pluginId, requestedId)` — a strict identity check (`resolveEnabledId(requestedId) === caller`) (`shell.qml:385-394`).

So with a cloned bar, the widget asking for its own service is asking *through the bar's scope*, and `pluginOwnsTarget("valiant.bar", "io.github.twiking.omasettings")` is false → `serviceFor()` returns `null` → the widget's `toggle()` is a no-op.

Panels are unaffected because the host injects each panel's **own** scope on load:

```qml
if ("shell" in item) item.shell = shell.pluginShellFor(panelEntry.manifest)  // shell.qml:1342
```

Bar widgets get `bar.shell` (the bar's scope) instead, so they have no equivalent path to their own service.

## Steps to reproduce

1. `omarchy plugin clone omarchy.bar <your-clone>` and set it as the active bar in `shell.json` (`"bar": { "id": "<your-clone>" }`).
2. Install a plugin that is **both** a `bar-widget` and a `service`, whose widget looks its service up with `bar.shell.serviceFor(<its own id>)` — `omasettings` is one.
3. Click its bar button.

Nothing happens. With the stock `omarchy.bar` the same plugin opens normally.

## Expected

A bar widget should be able to resolve **its own** service regardless of which bar is active — the same guarantee panels already have.

## Suggested direction

The bar hands each widget slot a reference to itself (`bar: root`). One option is for the bar to also hand each slot a scope for the widget's own plugin id, the way the panel loader already does, so `bar.shell.serviceFor(self)` resolves. A smaller alternative is to let a scoped api resolve a target when the caller is the **active bar** — a bar is already trusted with `pluginHasBarCapabilities` for other reasons — though that is a broader grant than the current identity check.

Happy to send a PR if there's appetite for either shape.

## Workaround

Call the plugin's IPC target directly instead of going through the scoped api:

```lua
o.bind("SUPER + SHIFT + S", "OmaSettings", "omarchy-shell omasettings toggle")
```

The IPC target is not permission-scoped, so it works.

## System

- Omarchy `4.0.4-1`
- Hyprland config: Lua (`hyprland.lua`), v0.56.2
- Bar: `valiant.bar`, a clone of `omarchy.bar`
- Wayland-only, NVIDIA GTX 970
- Reproduced on Omarchy's own `qs`/Quickshell shell; no `omarchy debug` subcommand exists in 4.0.4 so the log is not attached.