Add a search box to the Settings → Keyboard Shortcuts page

[DragonnZhang]

Closes #58

What & why

OpenWork's Settings → Keyboard Shortcuts page (ShortcutsPage.tsx) renders
every shortcut — the registry-driven actions grouped by category plus three
component-specific sections — for ~30 rows across many sections, with no way to
filter them. Finding "the toggle-theme shortcut" or "everything that uses ⇧"
meant scrolling and scanning the whole list.

Comparable desktop apps make their shortcut reference searchable: the Codex app's
Settings → Keyboard Shortcuts has "keypress search", and VS Code / Claude
keybindings both put a search box at the top. OpenWork's settings navigator
already got a search box (#40); the denser shortcuts list was the conspicuous
remaining un-filterable settings surface.

This adds a search box at the top of the Shortcuts page that filters the rows by
both the action label and the rendered key combination:

• typing theme narrows to the theme shortcut (label match);
• typing shift (or ⇧) narrows to every shortcut that uses Shift (keypress
  search — it matches the <kbd> key tokens, not just labels);
• sections with no remaining rows are hidden;
• a "No results found" empty state shows when nothing matches;
• a clear (✕) button and Esc reset the query;
• styling mirrors the existing settings-navigator search (icon, clear button,
  focus ring) for consistency.

Frontend-only. The page is a pure renderer view over the centralized action
registry (actionsByCategory + useActionRegistry().getHotkeyDisplay), so
filtering is client-side React state — no backend / qwen-code change. No new
i18n keys: the placeholder reuses common.search, the empty state
common.noResultsFound, and the clear button common.clear.

Changes

• pages/settings/ShortcutsPage.tsx — builds a flat, filterable section
  model from the registry (skipping hotkey-less actions) + the component-specific
  sections; adds the search input, label+key-token filtering, empty state, and
  clear/Esc handling.
• pages/settings/SettingsNavigator.tsx — adds
  data-testid="settings-item-<id>" to each settings-nav item so the e2e
  assertion can open the Shortcuts sub-page (a general, reusable test hook).
• e2e/assertions/shortcuts-search.assert.ts — new CDP assertion (below).

Verification (DoD)

• bun run typecheck:all — zero new errors. Delta vs main is zero: the
  only errors are the 11 pre-existing ones in apps/electron (auto-update.ts
owner/repo, a settings-default-thinking test tuple, two test files
  importing vitest) — none in the files this PR touches.
  packages/{core,shared,server-core,server,session-tools-core,ui} all pass
  clean.
• bun test — no new failures. The touched-area suites
  (src/renderer/actions, src/renderer/pages/settings) pass 3/3; no test
  references the changed files; the change adds zero i18n keys, so the
  pre-existing baseline (56 known failures, unrelated) is unchanged.
• bun run lint:i18n:parity — OK (6 locales, 1542 keys each — unchanged; no
  new keys).
• Renderer build (bun run electron:build:renderer, where this change lives)
  — ✅ builds cleanly.
• CDP assertion transpiles (bun build e2e/assertions/shortcuts-search.assert.ts)
  — ✅.

CDP e2e assertion (shortcuts-search.assert.ts)

Drives the real built app over CDP entirely in the draft (no-session) state — no
seeded conversation and no backend (the Shortcuts page is a pure registry view):

1. Open Settings → Keyboard Shortcuts from the sidebar; the search box
   renders and the list shows more than one shortcut row.
2. Type an action's label → the list narrows to exactly the predicted matches,
   every visible row contains the query, and the list shrinks.
3. Type a key token read from a rendered <kbd> chip → the list narrows to
   exactly the rows that use that key, and every visible row contains it —
   proving key/"keypress" search works, not just label search.
4. A no-match query shows the empty state and hides every row.
5. Clearing the query restores the full list.

⚠️ Local CDP run was blocked by this sandbox's egress policy, not by the
feature — the Electron binary download (GitHub release host) returns 403 from
the egress proxy, so the app can't be built/launched here (xvfb is present;
only the binary fetch fails), the same limitation noted on the other open
loop-bot PRs. The assertion transpiles and is included so CI / a reviewer can
run bun run e2e in an environment with normal network access. Everything that
doesn't require launching Electron (typecheck, unit tests, i18n parity,
renderer build) passes with zero delta vs main.

Part of the autonomous desktop-feature loop (loop-bot).

---

Generated by Claude Code