Fix for "C-s highlights but typing still edits the buffer" in the GPU
frontend. The GUI withholds Ctrl chords (`should_forward_key`) and
treated Escape as a hard quit, so it could neither *start* a search
(C-s never reached the daemon) nor route the query keys into one —
they fell through to the optimistic-apply path and edited the
document.
The GUI now mirrors the daemon's input-interception state. A new
`daemon_intercepts_keys` (true while a `SearchPrompt` is live or the
daemon reports `DispatchIdle { idle: false }`) gates the key path:
- While intercepting, every key round-trips to the daemon — no
optimistic apply — so chars extend the query, C-s/C-r step, BS
shortens, RET accepts, C-g cancels. This reuses the M11.6 gate
the optimistic path already honored; the new part is round-tripping
the *command* chords that `should_forward_key` would otherwise drop.
- While idle, C-s / C-r are forwarded as search-entry chords (still
withheld for every other Ctrl chord) so a search can begin. No
optimistic local idle-flip: the daemon's `DispatchIdle` /
`SearchPrompt` flip the gate one round-trip later, so a rebound C-s
that doesn't start a search can never wedge the gate.
- Escape cancels an active search (round-tripped to the daemon's
`SearchKey::Cancel`) instead of quitting the window; it stays the
local quit when nothing is intercepting.
Also aligns the GUI status band's empty-query prompt with the TUI
(`I-search: ` with no `[no match]` until a non-empty query misses).
Tests: `is_search_entry_chord` (C-s/C-r + Ctrl only; and the fact that
`should_forward_key` withholds it, which is what the entry path
exists to override). The end-to-end routing is GUI-window behavior,
validated manually.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Levi Neuwirth
2326fa6e32