## Summary

A cloned menu plugin (`omarchy plugin clone omarchy.menu`) receives a scoped
`PluginShellApi` whose `appLibrary` property is `null`, even though the
plugin manifest declares the `menu` kind. First-party menus work fine because
they get the full shell root instead of the scoped API.

**Result:** the clone's Apps submenu is empty.

## Environment

- Omarchy: 4.0.3-1 (rolling / latest mirror)
- Kernel: 7.2.3-arch1-3
- Desktop: Hyprland (Omarchy shell)
- CPU: Intel i7-6600U, GPU: Intel HD Graphics 520 (Skylake)
- Shell: Quickshell

## Steps to reproduce

1. `omarchy plugin clone omarchy.menu` (creates e.g. `~/.config/omarchy/plugins/<user>.menu`, replaces the built-in)
2. `omarchy restart shell`
3. Open the menu and navigate to **Apps**

**Observed:** the Apps submenu shows no applications.

**Expected:** the cloned menu behaves like the built-in `omarchy.menu` and
lists the installed desktop applications.

## Diagnosis

Inside the running clone the injected `shell` object is the scoped
`PluginShellApi`. `Object.keys(shell)` includes `appLibrary`, but its value is
`null`:

```
keys=[...,appLibrary,...] lib=null
```

The menu's own binding in `Menu.qml`:

```qml
readonly property var appLibrary: root.shell ? root.shell.appLibrary : null
```

so `root.appLibrary` is `null`, the Apps model stays empty. Notably this is
not about the app scan itself — enumerating `DesktopEntries.applications`
returns ~74 entries in the same session.

Relevant shell code (`/usr/share/omarchy/shell/shell.qml`):

```qml
// line 603-604
appLibrary: shell.manifestHasKind(manifest, "menu")
  ? shell.pluginAppLibraryFor(cacheKey, key) : null,
```

```qml
// line 423-441
function pluginAppLibraryFor(cacheKey, pluginId) {
  if (_pluginAppLibraryApis[cacheKey]) return _pluginAppLibraryApis[cacheKey]
  var api = pluginAppLibraryApiComponent.createObject(null, { ... })
  if (!api) return null
  ...
}
```

`manifestHasKind("zoltan.menu", "menu")` is `true` in the running clone
(`kinds === ["menu","bar-widget"]`), so the null must come from
`pluginAppLibraryFor()` returning `null` (i.e. the inner `createObject`
failing), or from the manifest object passed into `createScopedPluginShell`
not carrying the kinds when the scoped API is first built.

Isolated tests that do NOT reproduce the failure:
- `pluginAppLibraryApiComponent.createObject(null, {...})` directly — works.
- The same `createObject` nested inside another `createObject` init map (as
  `createScopedPluginShell` does) — works.

So the mechanism is fine in isolation; something in the live shell's load
path for third-party menu plugins yields the null.

## Workaround (applied locally)

Copy the stock `AppLibrary.qml` + `AppSearch.js` into the clone and fall back
to a local instance when `shell.appLibrary` is null:

```qml
AppLibrary { id: localAppLibrary }
readonly property var appLibrary: (root.shell && root.shell.appLibrary)
  ? root.shell.appLibrary : localAppLibrary
```

With this, the clone's Apps submenu lists the same 57 filtered entries as the
built-in menu.