## Summary

The bar-widget sandbox added in 4.0.3 removes the only path a third-party plugin had
to read the plugin registry, which silently breaks plugin-manager-style plugins. The
marketplace plugin [omaplug](https://github.com/fross100/omaplug) went from working to
showing "0 plugins · 0 enabled" across the 4.0.2 → 4.0.3 upgrade, with no error surfaced
to the user beyond one QML warning in the journal.

I am not arguing the sandbox is wrong — it is a clear improvement, and a plugin reaching
`bar.shell.pluginRegistry` to enumerate its peers was always relying on more access than
it was promised. This is about there being no supported replacement, and about the
breakage being silent.

## The change

`shell/plugins/bar/Bar.qml`, `injectProps()`:

```qml
// 4.0.2
if ("bar" in target) target.bar = root

// 4.0.3
if ("bar" in target) target.bar = firstParty
  ? root : root.pluginBarApiFor(pluginApiId, moduleName, registered)
```

Third-party widgets now get a `PluginBarApi` whose `.shell` is a `PluginShellApi`, which
declares no `pluginRegistry`. `pluginRegistryFor()` does hand out a `PluginRegistryApi`,
but per `services/PluginRegistryApi.qml` it is self-scoped — `installedPlugins` contains
only the calling plugin, and `isEnabled()` / `resolveEnabledId()` answer only for its own
id. There is therefore no API, sandboxed or otherwise, by which a plugin can enumerate
installed plugins.

## Two suggestions

**1. An opt-in registry-read capability.** Something a manifest can request, e.g.
`"capabilities": ["registry-read"]`, that widens `PluginRegistryApi` to a read-only view
of all installed manifests (id, name, version, author, kinds, enabled, source dir) —
mirroring what `omarchy plugin list --json` already prints to any process the user runs.
Enumeration is arguably not the sensitive part of the registry; live object references
are, and those would stay withheld.

**2. Surface the breakage.** A plugin that touches a property the sandbox no longer
provides currently fails as one `WARN scene: ... Unable to assign [undefined] to
QObject*` in the journal, and an empty panel in the UI. Since `omarchy update` can break
a marketplace plugin this way, it would help if the shell noticed and said so — even just
a notification naming the plugin.

## Related, but not the same thing

Two other 4.0.3 plugin-API regressions are already open, and both are accidents with
fixes:

- #10863 — `publicPluginManifest()` strips `__sourceDir`.
- #10871 / #10876 — `manifestHasKind()` uses `Array.isArray()` on what arrives as a
  `QVariantList`, so third-party menu plugins get a null `appLibrary`.

This one is different in kind: the sandbox is working exactly as designed. Nothing is
broken that a one-line fix would restore, which is why it needs a deliberate decision
about whether enumeration should be grantable at all, rather than a patch.

## Reproduce

1. Omarchy 4.0.2 with omaplug v1.3.0 installed and working.
2. `omarchy update` to 4.0.3-1.
3. Open the Plugin Manager: "0 plugins · 0 enabled".

Journal:

```
WARN scene: file:///home/prox/.config/omarchy/plugins/omaplug/Panel.qml[1358:5]:
  Unable to assign [undefined] to QObject*
```

## Environment

| | |
|---|---|
| Omarchy | 4.0.3-1 (broken; worked on 4.0.2-1) |
| Quickshell | 0.3.1-1 |
| Kernel | 7.2.3-arch1-3 |
| Hardware | Intel i7-1165G7, Iris Xe |

Downstream report: fross100/omaplug#19.