DOS door bridge: replay recent terminal output when the browser reconnects

[SkrawlCO]

TITLE: DOS door bridge: replay recent terminal output when the browser reconnects

Problem

When a browser's WebSocket to a running DOS door drops and reconnects within DOSDOOR_RECONNECT_TIMEOUT, the bridge reattaches the session but sends nothing until the door next writes. Output produced while the socket was down is discarded (WebSocket not ready, dropping N bytes).

Impact

After a brief network blip or tab reload, the player sees a blank terminal over a still-running door and has to guess the game state or restart.

Repair

• Each session keeps a bounded copy of the decoded terminal stream it sends to xterm.js (512 Ki string units, newest kept; a surrogate pair split at the cut is dropped).
• On reconnect the bridge sends that copy first, so the browser redraws the current screen.
• Output produced while the WebSocket is down is kept in the buffer, and the log says so, instead of being dropped silently.

Proof

The bridge script opens its listeners and a PostgreSQL connection when it loads, so it cannot be imported into a unit test without a database. Proof is:

• node --check on the changed script;
• a node:test harness that extracts and runs the exact append/trim statements from the file. It checks that the buffer stays within the bound and keeps the newest output, that small output is kept verbatim, and that the cut never leaves a lone low surrogate. 3/3 pass.

The reconnect path change is a single ws.send() of that buffer right after the existing setupWebSocketHandlers() call.