swarm-controller: end a dead replay, clamp stale resume ids, test on a real server

A replay consumer now has a 5s idle heartbeat, and the row stream ends at
the first consumer error instead of skipping it. When the server drops the
consumer, as on a restart, two missed heartbeats end the SSE response and
the browser reconnects with Last-Event-ID. Before, the response stayed
open and delivered nothing.

A Last-Event-ID above the stream's newest sequence now replays as a fresh
reader. The server accepts a start past the end and delivers nothing
until the stream reaches it, so a stale id stalled the replay.

swarm-controller's stream tests run against a real nats-server on
loopback (`test_nats`, binary from HIVE_NATS_SERVER, exported by
checks.nix and devshell.nix). They cover: ensuring the stream twice, an
existing stream with other limits being opened as it is, the replay
arriving before live rows, a reconnect getting every later row exactly
once, and a dropped consumer ending the row stream.

The limits test now compares against the subagent stream's own config.
Two comments that described the agent's terminal route as live-only are
corrected.

docs/swarm/ui.md

@@ -113,7 +113,10 @@ below `$SWARM.term.<agent>.sub`, so they never overlap.
 `GET /api/agents/<name>/term/stream` creates a short-lived consumer on it
 that starts 100 rows back, so the SSE stream sends those rows and then each
 new one. Each event's `id` is the row's stream sequence, and a request with
-`Last-Event-ID` resumes after it. Until the stream exists, the route sends
+`Last-Event-ID` resumes after it. An id past the newest row of the stream, as
+after swarm-controller recreates the stream, starts over as a fresh reader. When the
+consumer stops sending its heartbeat, as after a queue restart, the route ends
+the response and the browser reconnects. Until the stream exists, the route sends
 live rows only.
 
 </details>