fix: stop detach key tails from leaking into the surrounding shell

[kylecarbs]

Fixes the reported bug: detaching from boo attach with C-a C-d could kill the user's SSH session, and C-a d could leave a stray d typed at the prompt of the shell underneath. boo ui was unaffected.

Root cause

The detach round trip races the user's keyboard. The client exits as soon as the daemon acknowledges the detach, but the terminal keeps producing events for the key that triggered it:

• auto-repeats once the keyboard's repeat delay elapses (~225-660ms depending on OS), for as long as the key is held;
• kitty-protocol release reports, when the session app had mirrored event reporting onto the terminal;
• impatient re-presses (the detach gives no feedback for a full SSH round trip);
• anything already in flight across the SSH link.

The client's final TCSAFLUSH only discards bytes queued at that instant. Everything arriving a few milliseconds later is read by the login shell that regains the tty: a stray d at the prompt, or, for C-a C-d, a raw C-d that the shell reads as EOF, exiting it and tearing down the SSH session.

A second, daemon-side hole compounded the C-d case: input frames are parsed as a batch, and SSH commonly coalesces an auto-repeat right behind the command key (0x04 0x04 in one read). Bytes decoded after the detach dispatched in the same batch were still forwarded to the window, where the trailing C-d EOFed the session's program.

boo ui is immune because its prefix parsing is client-side and instant (no round trip, so the chord is released before repeats begin) and it never mirrors kitty key reporting onto the real terminal.

Reproduced with a PTY harness emulating a human typist (separate keystrokes, press/release/repeat timing, optional kitty CSI-u encoding, simulated SSH latency) under a real bash login shell: held C-a C-d reliably exited bash at 50ms latency, and held C-a d printed dddd at the restored prompt.

Fix

Client (src/client.zig): after writing the screen restore, keep reading and discarding tty input while still in raw mode (so nothing echoes), then hand the terminal back. Two timers bound the wait:

• an initial guard covering the silent gap between the triggering press and the first auto-repeat, then short quiet extensions while events keep arriving, capped at 1.5s;
• the guard is 300ms by default, 800ms when the tail is EOF-dangerous: a C-a C-d detach, or a session ending while attached (commonly a C-d typed at the session's own shell). Keyboard repeat delays reach ~660ms (Linux console default), and a leaked C-d is the SSH-session-killer, so that case gets the long guard; plain C-a d keeps the snappy guard so prompt handover stays quick and deliberate typing right after detach is not swallowed.

keys.Command.detach now carries the triggering byte, and the daemon reports C-d detaches as detached-eof. Old clients treat any non-stolen payload as a plain detach, so the protocol change is wire-compatible.

Daemon (src/daemon.zig): handleKeyCommand drops commands once the connection is no longer attached, so bytes coalesced behind the detach key in the same input batch can never reach the window.

Tradeoff, stated honestly

A tty hands us a byte stream, not key-up events, so "user still holds d with a slow repeat delay" and "user released and is about to type" are indistinguishable until the first repeat arrives. The 300ms guard for C-a d means a held d on a keyboard with a repeat delay above 300ms can still print a few ds; raising the guard would instead delay every detach and eat keystrokes typed deliberately right after. The catastrophic variant (C-d) always gets the long guard. If reports persist for the cosmetic case, a config knob (e.g. BOO_DETACH_DRAIN_MS) is the obvious follow-up.

Validation

• zig build test-all passes (Debug), zig fmt --check clean.
• Two new PTY integration tests run attach under a wrapping /bin/sh on the same tty (a login-shell stand-in) whose read exposes leaks: the command key is sent with a coalesced repeat, repeated until the restore sequence appears, plus one repeat after it (and, for the C-d case, a late repeat 600ms out modeling a slow keyboard). Both tests fail on main (the d variant corrupts the probe line; the C-d variant EOFs the shell and, before the daemon guard, killed the session's cat) and pass with the fix.
• 15 parser unit tests updated for the detach payload byte.
• The Python typist harness (legacy and kitty flags 1/3, 0-150ms simulated latency, tap/hold/release matrices) confirms: bash survives held C-a C-d everywhere, kitty release reports no longer spill 0;5:3u garbage, and single taps remain leak-free with no behavior change.

---

This PR was generated by Coder Agents on behalf of @kylecarbs.