fix(web, mobile): a failed terminal resize is sent again#32047

Problem

When a terminal.resize request fails while the WebSocket stays up, the client never sends the size again. The terminal surface only reports a grid when its measured size changes, and the resize result was dropped (reportFailure: false, result ignored). The PTY then keeps the old width indefinitely: stty size disagrees with the drawn pane, full-width output wraps, and spinners staircase, until the next drag to a new width. That matches the report: stty size printed 51 110 while the panel showed about 86 columns, and dragging again fixed it.

Reproduced on main (6577c6b618), web dev server, right-panel bash terminal, a 100 ms spinner, divider dragged mid-run. With every resize succeeding the PTY follows the pane (41 68 → 41 57). With exactly one resize request rejected by the server while the socket stays connected, the pane draws 44–46 columns but stty size stays at the previous width (53/60 columns) and the full-width line wraps, still stale more than a minute later with nothing touched.

This closes the failed-request path. What made the request fail on the reporter's macOS desktop is not confirmed (a node-pty resize throw surfaces as TerminalResizeError); the reproduction injects the failure.

Change

After a resize request fails, and the failure is not an interruption, the client resends the terminal's current grid once:

• Web and desktop, ThreadTerminalDrawer: on failure the drawer records the writable session generation and calls the surface's resendSize(), so the retry carries the current measured grid through the existing 150 ms debounce (resize commands are a latest-wins lane, so the failed size is never replayed over a newer one). The next report consumes the record; a retry's failure is not retried, and a record never carries over to another session generation.
• Mobile, createTerminalSession in packages/client-runtime: sendResize(retry) calls itself once with retry = true after a non-interrupt failure, re-checking the attachment generation and operate access. No shared state survives a detach or reconnect.

Failures stay silent. A request that keeps failing is sent at most twice; the existing per-generation replay on reconnect still applies. No server, contract or settings change.

Scope and approval

Fixes pingdotgg/t3code#31013

Triaged via the automated issue flow; reproduced on main with one injected resize failure.

Verification

Focused tests, each failing on main first:

• apps/web/src/components/ThreadTerminalDrawer.browser.test.tsx: resends the terminal size after a resize request fails (main: only one 57×41 resize reached the command) and resends a failed resize once in each writable session (a retry suppressed after the session stopped being writable, and the bound on persistent failure). 4/4 pass.
• packages/client-runtime/src/state/terminal.test.ts: sends each failed resize again once, in every attachment generation (a failure after detach is not resent, generation 2's failure is resent once, its retry's failure is not, a new grid gets its own retry). 13/13 pass.
• A mutation check removing the retry bound makes both suites fail (unbounded resend).
• vp run check:changed: format, lint, knip, typecheck, tests and React compiler pass.

Real-app recordings, web dev server in Chrome 156 on Linux, 1440×900, DPR 2, dark theme, fresh database per side, same driver on both sides. Each recording first shows a successful drag (68 → 53 columns), then one drag narrower whose resize frame is rewritten in the page to cols: 0 so the server rejects it ("Expected a value greater than or equal to 1"), with the socket open throughout:

The head adds only f6525a2d4c after the captured build, which swaps in the equivalent isAtomCommandInterrupted helper and edits tests. An independent rebuild at the head reproduced the recovery (retry 178 ms after the rejected send, PTY back at 44 columns). The recordings (as GIFs) are in a PR comment; the final before/after stills and a zero-threshold diff are in the reply to the CodeRabbit summary. The differences between the final stills are the probe output and wrapping, the completed spinner glyphs and the sidebar thread age.

Not verified: the reporter's natural failure on the macOS desktop app; mobile on a device (covered by the client-runtime test; no mobile rendering changed); the server path where resizeLocked ignores a resize from an unregistered viewer while another viewer has a size, which returns success and is not covered by this retry.

AI-assisted; verified with the tests and tools listed above.