### What happened

After updating to Omarchy 4.0.3, the Apps submenu in the Omarchy menu (the launcher) is empty — "0 entries" / "Nothing here yet" — for any menu plugin that isn't the first-party `omarchy.menu` (e.g. a theme's cloned copy created via `omarchy plugin clone omarchy.menu`, which is how per-theme menu customization is documented/supported).

### What was expected

The Apps submenu should list installed applications, same as it does for the stock (unmodified) menu.

### Root cause (traced)

This looks like a regression from the 4.0.3 change that moved the Apps submenu from a bash `.desktop` enumeration to Quickshell's native `DesktopEntries` service (see the comment in `shell/plugins/menu/Menu.qml`: "... (DesktopEntries) instead of a bash enumeration, so they carry image icons, launch feedback, and uninstall support like the launcher").

In `shell/shell.qml`, `createScopedPluginShell()` builds each plugin's `PluginShellApi` with:

```qml
appLibrary: shell.manifestHasKind(manifest, "menu")
  ? shell.pluginAppLibraryFor(cacheKey, key) : null,
```

For a cloned menu plugin (manifest `kinds: ["menu","bar-widget"]`, confirmed via a live dump of the manifest object), `manifestHasKind(manifest, "menu")` correctly evaluates `true`, but `shell.pluginAppLibraryFor(cacheKey, key)` still returns `null` for the plugin — I confirmed this live by instrumenting a cloned `Menu.qml` with a periodic `Timer` that logged `root.shell` (non-null, correct `PluginShellApi` with an `appLibrary` property present in its key list) vs `root.shell.appLibrary` (`null`).

This is *not* a `DesktopEntries`/Quickshell problem: a standalone `quickshell -p test.qml` script run in the same session correctly reported `DesktopEntries.applications.values.length` as 108 after ~3s (it populates asynchronously). The bug is specifically in the `shell.appLibrary` → third-party "menu"-kind plugin hand-off in `shell.qml`; `AppLibrary.qml` and `DesktopEntries` both work fine on their own.

Net effect: `Menu.qml`'s `root.appLibrary` (`root.shell ? root.shell.appLibrary : null`) resolves to `null`, so `mergeAppRows()` returns early and the Apps submenu never gets populated, for every third-party/cloned menu plugin.

### Steps to reproduce

1. `omarchy plugin clone omarchy.menu` (this is the documented way to theme/customize the menu, and switches the bar to the clone).
2. Restart the shell (`omarchy restart shell`).
3. Open the menu and navigate to Apps.
4. Apps shows 0 entries, even though `/usr/share/applications` and `~/.local/share/applications` have valid `.desktop` files and the stock `omarchy.menu` (before cloning) shows them fine.

### Environment

- `omarchy 4.0.3-1`
- `quickshell 0.3.1-1` (Quickshell 0.3.1)
- Hyprland 0.56.2, Arch Linux

### Screenshot

Attached: the cloned menu's Apps submenu showing "0 ENTRY" / "Nothing here yet" (theme is a custom clone, but the underlying bug reproduces with any cloned menu plugin — it's not theme-specific).

### Workaround

In the affected clone's `Menu.qml`, I worked around it by falling back to a locally-built app library (reading `DesktopEntries.applications.values` directly plus `gtk-launch`) whenever `root.shell.appLibrary` is null, rather than relying on the host-supplied `appLibrary`. Happy to share the patch if useful, though the real fix belongs in `shell.qml`'s plugin API wiring.

### Aside

Separately, `omarchy debug` (listed in `omarchy --help` under both "Common commands" and the `debug` group) currently fails with `Unknown Omarchy command: omarchy debug` on this same install, even though `/usr/bin/omarchy-debug` exists and runs fine when invoked directly. Didn't want to conflate two bugs in one issue — let me know if a separate report is wanted for that.