bug: interactive terminal session freezes long-running processes when the browser client disconnects

bug: interactive terminal session freezes long-running processes when the browser client disconnects

Bug description

Interactive (PTY) terminal sessions only drain their PTY output while a
browser WebSocket client is attached. If the client disconnects — closed tab,
suspended laptop, browser backgrounded/killed — nothing reads the PTY master
fd anymore, and the kernel PTY buffer (~64 KB) eventually fills up. Any
long-running process attached to the terminal (e.g. a CLI agent, a build, a
tail) then blocks on write() until a client reconnects. Output produced
while detached is also lost beyond the kernel buffer.

This makes the terminal unusable as a place to run anything long-lived that
produces output.

To Reproduce

1. Open an interactive terminal session and start a process that emits more than ~64 KB of output over time (e.g. yes | head -c 100M or a long build).
2. Close the browser tab (or let the connection drop) while it runs.
3. Reopen later and observe: the process is frozen once the kernel buffer filled, and output emitted while detached is gone.

Expected behavior

The child process should keep running — and its output should be retained —
independently of whether a browser client is connected, similar to how
command sessions already buffer output.

Suggested approach

• Move PTY draining into the session itself: a session-owned drain task started at session creation that reads PTY output into a capped in-memory buffer (with a monotonic byte counter), independent of clients.
• Make terminal_ws a subscriber that tails the session buffer via byte offset (same pattern as command sessions) instead of being the sole reader; reconnecting clients resume from their offset.
• On the frontend, re-establish the terminal WebSocket on visibilitychange if the connection died while the tab was hidden (browsers throttle/suspend background tabs and can silently kill the socket).

Environment

• Latest main

Start at the terminal_ws entry point and session creation, then compare how command sessions buffer output. Trace PTY master reads and the frontend visibilitychange handling. Done means the process continues and output is retained while disconnected, with reconnecting clients able to resume it.