fix: stop disowning a healthy client under output bursts

[wfaderhold21]

Reported as: on macOS, running omp would randomly detach the viewing session.

It is neither random nor omp-specific — it is the relay stall detector firing on a healthy client, and macOS makes it easy to trip.

Mechanism

Frames reach an attached client over the reattach socket with a 5s write timeout. Three consecutive timeouts were read as "this client is wedged" and answered with a forced AppEvent::Detach (src/main.rs:385-405). Nothing was wedged:

• macOS gives a unix socket an 8 KiB buffer (net.local.stream.sendspace) where Linux gives ~208 KiB — small enough that a single ratatui frame on a wide terminal can fill it.
• The server's BufWriter was the default 8 KiB and the client read in 4 KiB chunks, so one frame crossed the socket as many small blocking writes, each able to stall separately.
• omp is simply a chatty session: it drives redraws faster than the emulator drains. Linux's large buffer absorbs the burst; macOS's does not.

Separately, a SO_SNDTIMEO expiry surfaces as EAGAIN on Linux but can come back as ETIMEDOUT on BSD/macOS, which is_transient_terminal_error did not match. On that path a single timeout skipped the retry budget entirely and detached on the spot.

Changes

• reattach::widen_socket_buffers — request 512 KiB SO_SNDBUF/SO_RCVBUF on both ends (best-effort; the kernel clamps to kern.ipc.maxsockbuf).
• Server writes through a 64 KiB BufWriter; client drains in 64 KiB reads.
• ETIMEDOUT/TimedOut counted as transient slowness rather than a dead client.
• Stall budget 3 → RELAY_STALL_LIMIT = 12 (~60s). Safe: a client that has actually gone away is caught immediately by EOF on the relay reader, so this path only governs the stalled-but-connected case.

Testing

cargo clippy clean, cargo fmt applied, 402 tests pass.

Caveat worth a reviewer's attention: this was diagnosed from the code and not reproduced on macOS. The ETIMEDOUT gap is unambiguously a bug; the buffer sizing is the part that explains the "random" character. If detaches persist, the thing to check is whether they correlate with output bursts at all — if they happen while idle, the cause is elsewhere and the relay reader dropping the connection is the next suspect.

🤖 Generated with Claude Code