fix(tui): keep ssh-mangled mouse reports out of the composer

[plombeer31]

What

ssh from a Mac (iTerm2, then Terminal.app) into the TUI and the mouse layer "spams coordinates" as visible text while the app looks hung. Four layers of hardening, from most to least likely cause:

1. ESC-split hold (mouse-stdin.ts) — an ssh hop re-chunks the byte stream, so during a wheel/drag flood some read eventually ends exactly on a report's ESC. The decoder forwarded a chunk-final lone ESC as text (that is how the Escape key arrives), which typed the rest of the report — [<64;3;9M — straight into the composer. A chunk-final ESC is now held 10ms: if the rest of a report follows, they rejoin and decode; if nothing follows, it was the Escape key and flushes (well under Ink's own ~20ms lone-Esc deferral, so Escape feel is unchanged).
2. Decoder coverage (parse-mouse-events.ts) — urxvt/1015 reports (ESC [ 32;62;21 M) are now consumed instead of dropping through as text, with a button-code floor (≥32) so no keyboard CSI can be misread as one; truncated three-param CSI heads are buffered until their final byte so split sequences reach Ink whole; and 1005/UTF-8-extended is documented + covered — stdin is UTF-8-decoded before the parser, so it already lands in the X10 branch.
3. Leak breaker (mouse-stdin.ts + tui-command.ts) — if report-shaped text is about to reach Ink anyway (an encoding or mangling nobody anticipated), the shapes are stripped and mouse tracking is disabled for this session only (persisted preference untouched), with a one-line warn notice naming /mouse and --no-mouse. Trips on a burst (2 remnants in one read) or a slow drip (3 across the session, counted across read boundaries); a single report-shaped paste fragment does not trip it, and it never arms while the mouse is off. Post-trip stripping joins reads too (adversarial review caught it running per-chunk, which let a straggler split across reads — [<0;9 then ;9M — leak through after the trip): a chunk-final remnant prefix is withheld until the rest arrives or a 10ms timer rules it ordinary typing, mirroring the ESC-split hold.
4. Signal escalation (signal-escalation.ts) — the handlers were process.once, so a second SIGINT/SIGTERM/SIGHUP fell through to Node's default kill, which skips exit hooks and left the shell in mouse-reporting mode — every click printing [<0;64;21M at the prompt — and on the alt screen. Over ssh, a hang is exactly when people reach for a second Ctrl-C. The second signal now restores the terminal (via the existing terminal-restore.ts LIFO net) and exits 130.

Test evidence

• 22 new tests across parse-mouse-events.test.ts, mouse-stdin.test.ts, signal-escalation.test.ts, tui-command.mouse.test.ts (the original 18 — 11 proven to fail with the src files reverted to the old main, plus 2 pinning pre-existing behavior, 3 signal-escalation units and 2 negatives — and 4 from the review fix, all 4 proven to fail without the post-trip joining).
• Full src/tui/ tree on Node 25.9, after merging current main (v0.5.0, shift-drag selection): 238 files, 2581 tests, all pass (one unrelated runner-level EACCES from a local-models fixture spawning a fake llama-server binary; that file's tests pass).
• npm run lint clean.
• No in-repo PTY test: the failure needs an ssh hop's re-chunking, which a local PTY doesn't reproduce deterministically; the chunk-boundary behavior is instead pinned by the unit tests feeding the exact split byte sequences.

Known tradeoff (by design, called out in review): a bracketed paste containing two or more report-shaped fragments — say, a log of this very bug — trips the breaker, strips those substrings and disables the mouse for the session. The notice tells the operator and /mouse on turns tracking back on; treating paste markers specially was judged not worth the extra state for a paste that specific.

Reported on Discord: https://discord.com/channels/1515649306781155428/1515650562430079048/1542210929297461248