## What happened

Cloning the built-in Omarchy menu plugin (`omarchy plugin clone omarchy.menu`, producing a `menu` + `bar-widget` dual-kind clone) leads to the clone's Apps list rendering empty ("Nothing here yet") after a plugin rescan, even though app discovery itself is working fine. The stock, unmodified `omarchy.menu` plugin keeps working the whole time — only the cloned copy loses its app data.

## What I expected

The cloned menu plugin should keep behaving identically to the first-party one (same app list, populated from installed `.desktop` entries), since `omarchy plugin clone` is the documented, supported way to customize shell plugins.

## Steps to reproduce

1. `omarchy plugin clone omarchy.menu` (creates `~/.config/omarchy/plugins/<id>.menu/`, a manifest with `"kinds": ["menu", "bar-widget"]`, `"omarchy": {"clonedFrom": "omarchy.menu"}`)
2. `omarchy restart shell`
3. Open the launcher, go to Apps — list is populated, looks fine.
4. Trigger a plugin rescan (e.g. `omarchy-shell shell rescanPlugins`, or any local-plugin-file save that fires the shell's "Local plugin changed, reloading" path)
5. Open the launcher's Apps view again — the list is now empty, showing the "Nothing here yet" empty state.
6. The stock `omarchy.menu` plugin (if you disable the clone and go back to it) still shows the full app list at every point above — the bug is specific to the cloned instance.

## Root cause (traced this down before filing)

I added a temporary IPC-callable diagnostic (`debugApps()`) to the cloned `Menu.qml` to check what the plugin sees at runtime. On the cloned instance, right after a rescan:

```json
{"libOk": false, "count": -1, "err": "", "providersLoadedApps": false, "rowsLoaded": true, "hasAppsItem": true, "appsProvider": "apps"}
```

- `rowsLoaded: true` / `hasAppsItem: true` — the menu's own row/provider config is intact.
- `libOk: false` — `root.shell.appLibrary` (the shared `AppLibrary` service the shell is supposed to inject into every plugin instance) is `null`/`undefined` inside the cloned plugin's scope.
- `err: ""` — no exception is thrown when it's accessed; the reference is just silently absent, not broken.

This points at `shell.qml`'s plugin-shell construction path — `pluginShellCapabilityProfile()` (shell.qml:524) and `createScopedPluginShell()` (shell.qml:569) — which appears to cache a plugin's capability profile keyed off its manifest. For a cloned plugin that declares **both** `"menu"` and `"bar-widget"` kinds, a rescan can leave that cached profile in a state where the "has menu capability" check fails, so the scoped shell object handed to the plugin comes back without a live `appLibrary` reference — with no error surfaced anywhere (I checked journalctl around the failure window; only an unrelated `Qt.atob` deprecation warning, no exception).

I could reproduce this with a **byte-for-byte stock copy** of `plugins/menu/Menu.qml` placed under a cloned plugin ID, so it's not particular to any local edits — it's the clone + rescan interaction itself.

## Workaround I used

Rather than depend on `shell.appLibrary`, I gave my clone (`~/.config/omarchy/plugins/hermes.menu/`) its own private instance of the same engine, copying `services/AppLibrary.qml` and `services/AppSearch.js` in alongside the cloned `Menu.qml` and constructing a local `AppLibrary` instance directly instead of reading `root.shell.appLibrary`. That fully avoids the shared/cached facade and hasn't broken across multiple rescans in testing. This is a workaround for a single plugin, not a fix to the underlying capability-profile caching.

## System info

- Omarchy: 4.0.3-1 (build 4.0.3)
- Quickshell: 0.3.1-1
- Hyprland: 0.56.2
- Kernel: 7.2.3-arch1-3, x86_64
- Machine: MacBookAir7,2 (Intel i5-5250U / HD Graphics 6000, i915)

Full `omarchy debug --no-sudo --print` output: https://logs.omarchy.org/S3USMN (expires in 24h)

## Screenshot

Attached: the cloned menu's Apps view showing the empty state after the rescan.