## Apps menu shows "Nothing here yet" when a cloned menu plugin is active (Omarchy 4.0.3-1)

### Summary
The Apps launcher (`Super + Alt + Space`, `omarchy-menu toggle apps`) permanently shows an empty "Nothing here yet" state instead of the installed application list, when the active menu plugin is a **clone** of `omarchy.menu` (e.g. created via `omarchy plugin clone omarchy.menu`, as documented in the plugin customization guide). Disabling the clone and re-enabling the stock `omarchy.menu` plugin fixes it immediately, with no other change.

### Environment
- Omarchy: `4.0.3-1` (`BUILD_ID=4.0.3`)
- Hyprland compositor, Wayland session
- Kernel: `7.2.4-arch1-2`
- Reproduced on **both**:
  - `extra/quickshell 0.3.1-1` (as shipped)
  - `omarchy/quickshell-git 0.3.0.r20.g28771c7-3` (swapped in mid-investigation to rule out a quickshell regression — did **not** fix it)
- Active plugin setup: `dev.menu` (a clone of `omarchy.menu`, `kinds: ["menu","bar-widget"]`), `omarchy.menu` disabled while the clone is active — this is the standard state produced by cloning the menu plugin per Omarchy's own plugin-customization workflow.

### Steps to reproduce
1. Clone the menu plugin: `omarchy plugin clone omarchy.menu` (creates e.g. `~/.config/omarchy/plugins/dev.menu/`, disables `omarchy.menu`, enables the clone — matches this system's actual state, `omarchy-shell shell listPlugins` showing `dev.menu` enabled/`clonedFrom: omarchy.menu` and `omarchy.menu` disabled).
2. Open the Apps menu: press `Super + Alt + Space`, or run `omarchy-menu toggle apps`.
3. Observe: the menu opens with the "Apps…" search placeholder, an eye-slash icon, and the text "Nothing here yet" — no applications listed, regardless of query.
4. `omarchy restart shell`, waiting, disabling/re-enabling the clone via `omarchy-shell shell setPluginEnabled dev.menu false/true`, and even downgrading `quickshell` do not fix it.
5. Disable the clone and re-enable the stock plugin:
   ```
   omarchy-shell shell setPluginEnabled dev.menu false
   omarchy-shell shell setPluginEnabled omarchy.menu true
   ```
6. Re-open the Apps menu — it now populates correctly with all installed applications.

### What was ruled out (with evidence)
- **Not missing/misread desktop files.** `/usr/share/applications` + `~/.local/share/applications` contained 103 valid `.desktop` files; permissions and `XDG_DATA_DIRS`/`XDG_DATA_HOME` in the running shell process's environment (`/proc/<pid>/environ`) were correct and matched the interactive session's `systemctl --user show-environment`.
- **Not Quickshell's `DesktopEntries` scanner.** Running `quickshell -n -p <minimal-probe> -vv --log-rules "*.debug=true" --log-times` shows the `quickshell.desktopentry` category finding and parsing all 103 entries within **~3ms** of "Configuration Loaded" — far faster than any human interaction, so a first-open race against the scanner is implausible.
- **Not GIO/glib desktop indexing.** `python3 -c "... Gio.AppInfo.get_all() ..."` independently enumerated ~98 apps correctly from the identical shell environment.
- **Not over-aggressive hiding.** `/usr/share/omarchy/shell/services/hidden-entries.sh "$XDG_CURRENT_DESKTOP:$XDG_SESSION_DESKTOP:$DESKTOP_SESSION"` run directly correctly flagged only 31 of 103 entries as hidden (`Hidden`/`NoDisplay`/`OnlyShowIn`/`NotShowIn` semantics), not all of them.
- **Not the `quickshell` package version.** Symptom was byte-for-byte identical before and after swapping `extra/quickshell 0.3.1-1` → `omarchy/quickshell-git 0.3.0.r20.g28771c7-3`.
- **Not fixed by recreating the plugin instance.** Toggling the clone off/on via `setPluginEnabled`, and a full `omarchy restart shell`, left the same empty state.

### Suspected root cause (in source, not fully confirmed as the trigger)
In `/usr/share/omarchy/shell/shell.qml`:
```qml
appLibrary: shell.manifestHasKind(manifest, "menu")
  ? shell.pluginAppLibraryFor(cacheKey, key) : null,
```
`pluginAppLibraryFor()` builds a `PluginAppLibraryApi` proxy object (`/usr/share/omarchy/shell/services/PluginAppLibraryApi.qml`) for **any** menu-kind plugin, clone or first-party, to reach `shell.appLibrary`:
```qml
function pluginAppLibraryFor(cacheKey, pluginId) {
  if (_pluginAppLibraryApis[cacheKey]) return _pluginAppLibraryApis[cacheKey]
  var api = pluginAppLibraryApiComponent.createObject(null, {
    ownerPluginId: pluginId,
    _entryName: function(entry) { return shell.appLibrary.entryName(entry) },
    _sortedEntries: function(query) { return shell.appLibrary.sortedEntries(query) },
    ...
  })
  ...
}
```
`PluginAppLibraryApi.qml` declares its own signal:
```qml
signal appsChanged()
```
but **nothing in `pluginAppLibraryFor()` connects the real `AppLibrary.appsChanged` to this proxy signal.** Meanwhile, in the menu plugin itself (`plugins/menu/Menu.qml`, present identically in both the stock plugin and any clone):
```qml
Connections {
  target: root.appLibrary
  function onAppsChanged() {
    if (root.providersLoaded["apps"]) root.mergeAppRows()
  }
}
```
This is the menu's only self-healing mechanism for a stale/empty app list — and it listens on a proxy signal that can never fire, since it's never wired to the real `AppLibrary.appsChanged`. If `mergeAppRows()` ever runs once and captures zero rows for any reason (`root.appLibrary` momentarily unready, a transient empty read, etc.), `providersLoaded["apps"]` is latched `true` and the empty result is cached for the lifetime of that plugin instance, with no path back to a correct state short of destroying and recreating the plugin (or, empirically here, switching identity back to the un-cloned stock plugin).

This would explain why the bug tracks specifically with **cloned** menu plugins in multiple independent reports, since cloning is the normal, documented way to customize `omarchy.menu`, and any transient hiccup during a clone's first load has no recovery path.

### Suggested fix direction
In `pluginAppLibraryFor()`, forward the real signal to the proxy, e.g.:
```qml
var api = pluginAppLibraryApiComponent.createObject(null, { ... })
shell.appLibrary.appsChanged.connect(api.appsChanged)
```
so Menu.qml's existing self-healing `Connections` block actually fires and re-runs `mergeAppRows()` after any real app-list change, instead of only ever seeing whatever `sortedEntries()` returned on the very first call.

### Workaround (confirmed working)
```
omarchy-shell shell setPluginEnabled <clone-id> false
omarchy-shell shell setPluginEnabled omarchy.menu true
```
Trades away menu customizations in the clone until the underlying plugin/signal-forwarding issue is fixed upstream.