client: restore scrollback search (Ctrl+Shift+F)

[dolonet]

Summary

Reverts #48. That PR removed @xterm/addon-search scrollback search on
the premise that browser-native Cmd+F / Ctrl+F covers the use case.

It doesn't. Browser find searches the rendered DOM, and the xterm DOM
renderer virtualizes rows — only the visible viewport is in the DOM, not
scrollback. Browser find searches the current screen; the removed
feature searched terminal history. PR #48 kept server-side
tmux capture-pane export as the "full history" path, but that's a
non-interactive dump, not in-terminal search — the capability had no
equivalent left.

What's restored (exact inverse of #48)

• SearchAddon + per-pane instance + the @xterm/addon-search@0.15.0 tag
• Per-pane search bar (input + prev/next/close) and .search-bar CSS
• Toolbar 🔍 button — also covers the "undocumented hotkey" point from
  client: drop scrollback search (Ctrl+Shift+F) #48, since the binding is now discoverable in the UI
• Ctrl+Shift+F binding + the delegated Enter/Escape handler
• Frontend test mock for SearchAddon

Performance note

The slowness in xtermjs/xterm.js#5176 only appears once highlightLimit
is raised to ~5k+. websh uses the addon default (1000), well inside the
freeze-free range (~22 ms highlight-all, 60 fps scroll per published
benchmarks). No local patch or pinned fork needed.

Test plan

• Frontend tests: 504/504 pass on this branch
• Search verified end-to-end — headless Chromium + Playwright (the frontend
  suite mocks SearchAddon, so the real addon path needs a live check):
  python3 server.py → localhost SSH, non-persistent pane, ~3000 lines of
  scrollback. Ctrl+Shift+F opens the bar (positioned correctly), matches
  highlight, Enter / Shift+Enter cycle next/prev through deep scrollback,
  Esc closes. 0 console errors.

[dolonet]

Self-review

Straight revert of #48 — restored code is identical to what #48 removed; no hand-written code. Checked that it still integrates after the changes since the drop (mostly the vault work — #66/#67/#69/#70/#71).

Verified:

• Exact inverse of client: drop scrollback search (Ctrl+Shift+F) #48: +46/−2 across the same 3 files.
• No symbol collisions — one definition each of toggleSearch, the Ctrl+Shift+F binding, and the .search-bar CSS rule.
• Ctrl+Shift+F re-inserted as the first branch of the keydown handler at websh.js:4205 — distinct chord, scoped preventDefault, no overlap with the zoom / F11 / Ctrl+Tab / Escape branches alongside it.
• The restored delegated handler (websh.js:3572) is gated on e.target.closest('[data-search]'), so it doesn't interfere with the other four document keydown handlers (legacy update, sign-out modal focus-trap, options-Escape, panel). The sign-out focus-trap handles only Tab — no chord collision.
• Frontend tests: 504/504 pass on the branch, vault suite included.

Not verified — manual smoke needed before merge:

• Live browser: search bar rendering, the .search-bar top:28px offset against current pane chrome, and actual find/highlight behaviour. The frontend tests mock SearchAddon, so the real addon path isn't exercised.

Pre-existing behaviour, restored verbatim (not a regression introduced here):

• Escape closes the search bar only when focus is inside it; with focus back in the terminal the bar stays open. Unchanged from before client: drop scrollback search (Ctrl+Shift+F) #48.

@gorevds — heads up, this reverts your #48. Rationale is in the description: browser Ctrl+F only sees the virtualized DOM viewport, not scrollback, so it isn't an equivalent for the removed scrollback search. Happy to discuss if you read it differently.