## What happened

The Apps submenu of the Omarchy Quickshell menu (`Super+Space` → Apps, or `Super+Alt+Space`) always renders "Nothing here yet", in every session, 100% reproducible. This is not a first-run-only race: restarting the shell, clearing `~/.cache/quickshell/qmlcache`, waiting 30-45s before first opening Apps, and forcing a plugin rescan (`omarchy-shell shell rescanPlugins`) all fail to fix it for the remainder of the session.

## What was expected

The Apps submenu should list installed applications (desktop entries), as it did before this regression.

## Steps to reproduce

1. Press `Super+Space` to open the Omarchy menu, navigate to Apps (or run `omarchy-menu toggle apps` directly).
2. Observe the Apps panel shows the "Nothing here yet" empty state instead of the app list.

## Diagnosis

- `omarchy` package was upgraded `4.0.2-1` → `4.0.3-1` on 2026-09-08 21:38 local time. `AppLibrary.qml`, `Menu.qml`, and `shell.qml` under `$OMARCHY_PATH/shell/` all carry that exact update timestamp, so this looks like a regression introduced in that release.
- Confirmed Quickshell's core `DesktopEntries.applications` singleton *does* populate correctly and quickly (verified via `quickshell -vv`, journal shows 98 "Found desktop entry" lines within under a second of shell startup, matching the 98 `.desktop` files on disk across `/usr/share/applications` and `~/.local/share/applications`).
- Confirmed the hidden-entries filtering (`shell/services/hidden-entries.sh`) is not over-hiding — it only hides ~60 of the 98 entries as designed, leaving ~36 that should be visible.
- Confirmed the menu JSONC config (`"apps": {..., "provider":"apps"}` in `default/omarchy/omarchy-menu.jsonc`) and the `omarchy.menu` plugin manifest (`"kinds": ["menu","bar-widget"]`) are both correct — so `shell.manifestHasKind(manifest, "menu")` should be true and `Menu.qml`'s `root.appLibrary` should not be null.
- Despite all of the above, `AppLibrary.mergeAppRows()` (called from `Menu.qml`'s `startProviderForMenu` the first time the Apps route is entered) ends up caching an empty row set, and it never recovers afterward — even a locally-patched menu plugin clone that retried `root.appLibrary.sortedEntries("")` in a loop for 4.5s straight (15 attempts, 300ms apart) kept getting an empty array back, despite the journal proving `DesktopEntries.applications` was populated with 98 entries in that same process.
- Separately, the third-party/plugin-facing `PluginAppLibraryApi` (`shell/services/PluginAppLibraryApi.qml`) declares its own `appsChanged` signal, but nothing in `shell.qml`'s `pluginAppLibraryFor()` wiring forwards the real `AppLibrary.appsChanged` signal into it — so even if a plugin's first read loses a genuine startup race, the self-heal path (`Menu.qml`'s `Connections { target: root.appLibrary; function onAppsChanged() {...} }`) can never fire. This looks like a real (if secondary) bug regardless of the primary cause above.

I was not able to identify the exact point where the populated `DesktopEntries.applications.values` fails to reach `AppLibrary.sortedEntries()`'s result inside the full shell process (it reproduces only in the full `shell.qml` graph, not in a minimal standalone Quickshell script that touches `DesktopEntries` directly), so I could not produce a working patch without deeper QML debugging tools.

## System

- `omarchy version`: 4.0.3-1
- `quickshell`: 0.3.1-1
- `hyprland`: 0.56.2-2
- CPU: AMD Ryzen 5 PRO 4650U
- GPU: AMD Radeon Vega (amdgpu), Wayland/Hyprland

## Attachment

Screenshot of the reproduced bug will be attached via the GitHub web UI (drag-and-drop) since `gh` can't upload media from the CLI.