fix(ui): bound queued terminal input, stagger wake reconnects, remove dead reconnect state

[0xabstracted]

Context

The web terminal transport (maestro-ui/src/platform/terminal.ts) reconnects on wake/refresh
(#140) and resumes from a byte offset (#136). Three robustness gaps remain in the client
transport around reconnect behavior.

Problems

1. Unbounded queued input. Keystrokes typed while the socket is not OPEN are queued to flush
on reconnect. There is no cap: a session left disconnected while a user (or a paste, or an
auto-typing tool) produces input can grow the queue without bound, and the whole backlog is
flushed at once on reconnect — a latent memory/flood risk.

2. Synchronized wake reconnects (thundering herd). On wake/visibility-restore, every open
terminal reconnects at once. With many hosted terminals this is a synchronized burst of /pty
handshakes (each doing a getReplay + replay send) against the server at the same instant.

3. Dead reconnect state. After offset resume moved the repaint decision out of the reconnect
path, some reconnect-era state/flags in terminal.ts are no longer read. Dead state invites
future desync bugs and misleads readers about what actually drives a reset.

Acceptance criteria

• Pending-input queue is bounded (cap by bytes and/or entries); when full, drop oldest or
  refuse-and-signal per an explicit, documented policy — never grow without bound.
• Wake/visibility reconnects are staggered (jittered/backoff) so N terminals do not all
  handshake in the same tick; a single terminal still reconnects promptly.
• Reconnect state in terminal.ts that is no longer read post-offset-resume is removed; a
  comment or test documents the single source of truth for "when does the terminal reset."
• Tests cover: queue cap enforcement + flush order, staggered reconnect scheduling, and no
  regression in single-terminal wake resume.

Refs

Foundation #140, offset-resume #136. File: maestro-ui/src/platform/terminal.ts (+ its
__tests__).