[BUG] SSH remote: message exceeding server line buffer wedges connection in infinite reconnect loop (token too long + stdin replay poison pill)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet (closest is #8659 — same scanner error but a different surface: headless --print stdout reading; this report is about the desktop app's SSH remote-session transport)
• [x] This is a single bug report
• [x] I am using the latest version

Environment

• Claude desktop app 1.11847.5.0 (arm64, Microsoft Store) on Windows 11 (10.0.26200, Snapdragon Surface)
• Remote host: linux-arm64 (NVIDIA DGX Spark, Ubuntu), connected via the app's SSH remote sessions feature
• Remote server binary 7cbfa471529b0dd33a5cc2f69c41c11bfe7fef6f, ccd-cli 2.1.170
• SSH over Tailscale (direct path, same LAN); network verified healthy throughout

What's Wrong?

A single chat message large enough to exceed the remote server's line-buffer limit (~2.2 MB in my case — e.g. a large paste) permanently wedges the entire SSH remote connection in a reconnect loop that never resolves:

1. The client sends each message as one JSON line over the shared RPC stream. A ~2,185,392-byte line hits the Go server's scanner limit; the server logs bufio.Scanner: token too long and closes the connection.
2. The client then re-queues the exact same stdin payload and replays it on the next rebind, which kills the connection again immediately.
3. Result: a fresh SSH connection every ~2 seconds, each one authenticating successfully, rebinding, replaying the poison payload, and dying. I observed 1,692 iterations over 72 minutes (11:59–13:11) until I restarted the app. There is no backoff growth, no poison-pill detection, and no user-visible error other than the generic "Lost connection / auto-reconnect didn't succeed" banner with a "Try again" button that cannot help.
4. Because all sessions share one transport, one poisoned session repeatedly takes down connectivity for every other session in the app.

Only restarting the desktop app clears the in-memory replay queue. The "session preserved, resend your message" banner advice doesn't apply — resending isn't the problem; the queued payload is.

What Should Happen?

• The server should accept (or chunk/stream) large stdin frames rather than relying on a line-scanner limit far below what the client will happily send — or the client should enforce the same max message size up front and surface a clear "message too large" error.
• The client's replay logic should detect that the same payload has fatally killed the transport N times in a row, dead-letter it, and tell the user — instead of replaying it forever.

Error Messages/Logs

Client (%APPDATA%\Claude\logs\ssh.log), repeating every ~2 s:

2026-06-10 13:11:17 [info] [RemoteServerController] Connected to remote server (673ms, trigger: warm_up, reused: true)
2026-06-10 13:11:17 [info] [RemoteServerController] Rebinding 2 live process(es)
2026-06-10 13:11:17 [info] [RemoteProcess:dc608b49-...] Reattached (running=true, lastSeq=212)
2026-06-10 13:11:17 [info] [RemoteRPCClient] Stream closed
2026-06-10 13:11:17 [warn] [RemoteServerController] RPC stream closed
2026-06-10 13:11:17 [info] [RemoteServerController] Auto-reconnect attempt 1 in 830ms (liveProcesses=2, elapsed=0s)
2026-06-10 13:11:17 [info] [RemoteProcess:dc608b49-...] Transport closed; entering detached state (grace=900000ms)
2026-06-10 13:11:17 [info] [RemoteProcess:dc608b49-...] Re-queued 2185583B of stdin after transport drop; will replay on next rebind

Remote server (~/.claude/remote/run/<id>/remote-server.log), matching every cycle:

2026/06/10 13:11:59 [Server] New connection from: @
2026/06/10 13:11:59 [Server] scanner error on @: bufio.Scanner: token too long
2026/06/10 13:11:59 [Server] Connection closed: @

Also seen once the loop is active, as collateral:

[error] [RemoteProcess:9749790b-...] Spawn failed: Not connected to remote server

Steps to Reproduce

1. Connect the desktop app to a remote host over SSH and start a session.
2. Send a message whose serialized stream-json line exceeds the server's scanner buffer (~2 MB; a multi-MB text paste does it).
3. Observe the reconnect loop in ssh.log (Re-queued NNNNNNNB of stdin) and token too long in the remote remote-server.log; banner reappears every few seconds; all sessions on that host are disrupted until the app is fully restarted.