fix(app): webview zoom via in-document CSS capture (amicode#266)

[gennadiryan]

What / why

amicode#266 — Cmd/Ctrl +/-/0 zoom keybindings did nothing while focus was inside the amicode webview. Root cause: the chords were registered with the command registry, whose exact (normalized-key, modifier-mask) matching is layout-sensitive (Ctrl+Plus on US IS Ctrl+Shift+"=" → arrives as key "+" with the shift bit; the numpad "+" arrives unshifted; on DE/FR/Nordic layouts "=" itself is shifted), and inside the webview the workbench can never see in-iframe keydowns to forward them.

Fix (V1): every app document — the main frame and each split pane — captures the chords itself with a raw capture-phase keydown listener (Ctrl/Cmd + =/+/-/_/0, matched by the key the layout produces, shift-insensitive) and applies the existing per-window persisted CSS zoom (web-zoom.ts). Zoom is in-app and self-contained; the extension needs no zoom machinery at all (companion PR in harmoniqs/amicode removes it).

• web-zoom.ts — raw chord capture → setWebZoom in all hosts; deleted the bridge envelope, pane relay, diag relay, and inWebview() routing.
• layout.tsx — deleted the view.zoomIn/Out/Reset registry entries and their layout-sensitive chord sets.
• tests — rewrote web-zoom.test.ts + zoom-keybind.test.ts around the raw listener (chord matrix + negatives).

Verification

• 9/9 app tests; bun run typecheck clean except the pre-existing session-header.tsx error.
• Remote GUI: panel focus → single CSS zoom of the webview content; tab focus → single native window zoom; no doubles, no bridge.

References harmoniqs/amicode#266.