Built-in terminal is slow to reopen and unreliable under sustained output

[Diffuzmetall]

Workflow

Use the built-in terminal for long-running commands on an enrolled remote machine, then close and reopen the terminal panel or reconnect the browser websocket.

What happens

Terminal output is forwarded as many tiny websocket messages, browser/daemon websocket buffers have no bounded transport policy, and every browser attach replays up to the full 4 MiB daemon scrollback from sequence zero. Under sustained output this makes input latency spiky, and reopening a populated remote terminal visibly scrolls through old output before reaching the prompt.

Measured on a terminal attached to a VPS:

• reopening an 8 MiB-populated terminal replayed 4,192,407 bytes in 1,025 websocket output messages;
• reaching the final replayed line took about 2.21 seconds;
• large pastes and multibyte input can be split at unsafe boundaries;
• attach/replay, close/exit, reconnect, and concurrent restart paths have race windows.

Expected

• Batch PTY output while preserving byte order.
• Bound browser and daemon websocket queues and isolate slow/broken sockets.
• Keep input responsive during output floods.
• Preserve arbitrary input/output bytes.
• Reconnect from the last received sequence and bound initial browser replay to a useful tail.
• Preserve final output before exit and make restart atomic.
• Render modern Unicode widths correctly and avoid conflicting multi-client resize updates.

Validation target

A populated remote terminal should open near its current prompt rather than replaying/scanning the entire retained scrollback, without silently losing output or input.

[ymichael]

thanks for doing this! will take look!