fix(keybinds): SUPER+? never fired — shifted keysym needs SHIFT in the modmask

? is typed as Shift+/, so Hyprland saw mods SUPER+SHIFT with keysym
`question` and the exact-modmask match skipped the `$mod, question`
bind — the keypress fell through to the focused window (caught on the
Latitude, BACKLOG item 26; the menu itself was fine from a terminal).

- keybinds.nix: bind is now `$mod SHIFT, question`.
- rofi.nix prettyKeys collapses "SHIFT + ?" back to "?" so the
  cheatsheet row keeps the documented SUPER + ? label.
- MEMORY.md gotcha: shifted keysyms need SHIFT in mods — invisible to
  eval-tier tests.

Verified: V0 (flake check --no-build); V1 both surfaces (eval'd
settings.bind renders `$mod SHIFT, question, exec, nomarchy-menu
keybinds`; built nomarchy-menu's cheatsheet renders `SUPER + ?`).
V3 queued: SUPER+? on the Latitude after home-update + relogin.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

agent/HARDWARE-QUEUE.md

@@ -33,7 +33,12 @@ QA machine), the **T14s** (webcam case).
       no comma layout was configured, so the bind wasn't rendered (the
       gate working as designed, not a failure) — retest after setting a
       comma layout + rebuild + relogin. The SUPER+? no-op found en
-      route IS a real bug → BACKLOG item 26.
+      route IS a real bug → BACKLOG item 26 (fix shipped — see the
+      dedicated SUPER+? entry below).
+- [ ] **SUPER+? opens the cheatsheet** (item 26 fix) — after
+      `home-update` + relogin (or `hyprctl reload`), SUPER+? must open
+      the keybindings cheatsheet, whose row still reads `SUPER + ?`
+      (not `SUPER + SHIFT + ?`).
 - [ ] **Keyboard hotplug picker (re-verify after in-flake graduation)** —
       plug an external keyboard post-login, pick a layout in rofi, confirm
       it applies per-device only, persists in `settings.keyboard.devices`,