fix(tui): drop corrupted SGR mouse garbage that leaked into composer

[konsisumer]

What changed and why

Under heavy render backpressure in tmux/WezTerm, dozens of SGR mouse events accumulate in the tty buffer. The 50 ms flush timer splits ESC from its continuation bytes, so subsequent reads arrive as plain text. parseTextWithSgrMouseFragments already recovers adjacent valid fragments as a burst, but the corrupted/partial bytes surrounding those matches (e.g. 5;34M;34M — fragments with only one semicolon, or two consecutive M terminators) were passed verbatim to parseKeypress, which emitted them as garbage text into the composer.

This PR adds MOUSE_GARBAGE_RE (/^[\d;Mm\[<]+$/) and applies it to any gap or tail text adjacent to a consumed burst: if the slice consists solely of characters that appear in SGR mouse event streams, it is silently discarded. Real trailing text (e.g. user-typed 'hello') is unaffected because it contains non-mouse characters.

The bug was reported by two independent users:

• Original reporter on Linux/WSL2 + tmux, reproducing with ~271k-token sessions
• iseppe on WSL2 Ubuntu 24.04 + WezTerm, triggered by double-clicking a link

Both environments confirm the leakage is not tmux-specific but inherent to the fragment-recovery fallback when mouse events arrive faster than the event loop can drain stdin.

How to test

1. Start hermes --tui inside tmux or WezTerm with mouse tracking enabled (default display.tui_mouse: true or all)
2. Open a large session (200k+ tokens) to create render backpressure
3. Move the mouse rapidly across the terminal for several seconds
4. Verify the composer (›) stays clean — no digit;digit;digitM garbage
5. Run the unit tests: cd ui-tui && npm test -- packages/hermes-ink/src/ink/parse-keypress.test.ts
   • 19 tests pass including 4 new regression tests for the garbage-drop behavior

What platforms tested on

• macOS (unit tests only; the parser fix is platform-agnostic)
• Reported affected platforms: Linux/WSL2 + tmux, Linux/WSL2 + WezTerm

Fixes #18658

[alt-glitch]

Part of the SGR mouse sequence leakage chain: #17701→#18113→#26781→#28463→#29337. Fixes #18658. Competes with open PRs #26781 and #29337 for the same bug.

[konsisumer]

Thanks @alt-glitch for the chain context.

I see two open PRs already targeting the same root cause:

• fix(tui): swallow degraded SGR mouse bursts instead of leaking to prompt #26781 (OutThisLife) — burst-noise fast path + burst-edge extension in parseTextWithSgrMouseFragments (82 additions)
• fix(hermes-ink): suppress SGR mouse fragments split across flush boundaries #29337 (Mamidi7) — 1-field and 2-field fragment guards in InputEvent.parseKey (26 additions)

This PR uses a MOUSE_GARBAGE_RE whitelist to silently discard gap/tail text composed solely of mouse-alphabet characters adjacent to a matched burst — a different strategy than either of the above, but same root cause and same affected file.

Should I close this PR in favor of one of the existing ones, or is there value in keeping all three open while a canonical fix is chosen? Happy to close and redirect effort to whichever approach you prefer.

[teknium1]

Closing as redundant against current main.

This is part of the TUI/CLI ANSI/SGR/escape-leak cluster, most of which is already solved on main:

• In-buffer CPR/DSR + SGR mouse (esc / visible / bare) stripping lives in cli.py::_strip_leaked_terminal_responses_with_meta().
• SGR mouse-burst noise, fragment recovery, and X10 wheel-tail handling live in ui-tui/packages/hermes-ink/src/ink/parse-keypress.ts (shipped via fix(tui): swallow degraded mouse-burst noise so a stalled loop can't lock the composer #35512 and follow-ups).
• The exit-side leak (focus/mouse modes left enabled after Ctrl+C/SIGTERM leaking into the next shell) was just fixed in fix(cli): reset terminal input modes on TUI exit to stop focus/mouse leaks #36864.

Your work here overlapped this already-merged coverage. Thanks for the contribution and for helping surface the leak class — it's appreciated.