### Summary

`SUPER + ESCAPE` (the default "System menu" binding) does not open the System menu. Instead it opens an empty submenu titled **"Htop"** that reads *"Nothing here yet"*.

The keybinding itself is correct. The cause is in `Menu.qml`'s `resolveRoute()`: it scans every item's **aliases before** considering the input as a literal item id, and app rows inherit their `.desktop` `Keywords` as aliases. Both `htop.desktop` and `btop.desktop` ship `Keywords=system;...`, so the route `system` resolves to an app row instead of the built-in `system` menu.

### Environment

- Omarchy `4.0.0.r1508.g12af188-1` (Quattro pre-release)
- Confirmed still present on `quattro` @ `HEAD` — `shell/plugins/menu/Menu.qml` L840-852 is unchanged.
- Requires `htop` and/or `btop` to be installed (both are common; `btop` ships in Omarchy's own `btop.conf` config).

### Steps to reproduce

1. Ensure `htop` or `btop` is installed (`/usr/share/applications/htop.desktop` present).
2. Press `SUPER + ESCAPE`, or run `omarchy-menu summon system`.

**Expected:** the System menu (Screensaver, Lock, Suspend, Hibernate, Logout, Reboot, Shutdown).

**Actual:** an empty menu titled "Htop" showing *"Nothing here yet"*.

### Root cause

`shell/plugins/menu/Menu.qml` L840-852 — the literal id is only reached as a fallback *after* the full alias scan:

```qml
function resolveRoute(input) {
  var raw = String(input || "").toLowerCase().replace(/_/g, "-")
  if (!raw || raw === "go" || raw === "menu") return "root"
  for (var i = 0; i < root.itemOrder.length; i++) {
    var entry = root.items[root.itemOrder[i]]
    if (!entry || !entry.aliases) continue
    for (var j = 0; j < entry.aliases.length; j++) {
      var alias = String(entry.aliases[j] || "").toLowerCase().replace(/_/g, "-")
      if (alias === raw) return entry.id     // ← app keyword wins here
    }
  }
  return raw                                  // ← real id never reached
}
```

App rows are built at L288-316 with their desktop `Keywords` as aliases:

```qml
var aliases = subtext ? [subtext] : []
if (entry.keywords && typeof entry.keywords.join === "function")
  aliases = aliases.concat(entry.keywords)
```

`htop.desktop` declares `Keywords=system;process;task;resources;monitoring;performance;`, so `resolveRoute("system")` returns the htop app row rather than `"system"`.

The result is an empty menu rather than a launch because app rows have `kind: "app"` and `action: ""`, so `openRoute()` (L854-869) matches neither the `action` branch nor the `link` branch and falls through to `openExistingMenu()` on a node with no children.

Note that the built-in `"system"` item declares `aliases:["power-menu"]` — not `"system"` — so nothing shadows the app keyword back.

### Blast radius

I diffed all 301 ids in `default/omarchy/omarchy-menu.jsonc` against every `.desktop` `Keywords`/`GenericName` on a stock install: **`system` is the only shadowed route.** But it's the one bound to `SUPER + ESCAPE` by default, so it affects any install with htop or btop present.

### Suggested fix

Give exact ids precedence over aliases:

```qml
function resolveRoute(input) {
  var raw = String(input || "").toLowerCase().replace(/_/g, "-")
  if (!raw || raw === "go" || raw === "menu") return "root"
  if (root.items[raw]) return raw   // exact id wins over any alias
  // ...existing alias scan...
}
```

Worth considering separately: app `Keywords` are useful for *search* but arguably shouldn't be routable aliases at all, since any future menu id can collide with an arbitrary third-party `.desktop` file.

### Workaround

Rebind to the System menu's own unambiguous alias in `~/.config/hypr/bindings.lua`:

```lua
hl.unbind("SUPER + ESCAPE")
o.bind("SUPER + ESCAPE", "System menu", "omarchy-menu toggle power-menu")
```

### Related

#6508 touches `resolveRoute`/`canonicalRoute` (link-following and toggle route-switching) but does not change alias-vs-id precedence, so this should survive that PR.