fix: harden the run relay + workspace sandbox against resource exhaustion

[suleimansh]

Closes #283.

A hardening pass over the code shipped this session (relay #230, sandbox #229), cross-checked by an independent adversarial review. Four real resource issues fixed; the first two are remote memory-exhaustion vectors since the relay is unauthenticated and binds 0.0.0.0.

1. Relay caps in-memory runs (LRU). GET /r/<id>/events and POST .../publish used to lazily create a per-run EventStream that was never freed, so an anonymous caller looping over random ids exhausted memory. Now bounded by maxRuns (default 200) with least-recently-used eviction (evicted runs close their stream and drop viewers).
2. SSE disconnect no longer leaks. EventStream iterators gained a return() that drops the waiter and settles a pending next(); serveSSE calls it on req close. Previously a dropped viewer's waiter lingered on the stream until the next event (never, for an idle run). This also fixes the same latent leak on the localhost dashboard.
3. Sandbox checks size before reading. snapshotWorkspace now stats a file and skips it if oversized, instead of reading the whole thing into memory first (avoids an OOM on a large workspace asset during --sandbox docker sync).
4. Publisher POST has a timeout. relayPublisher adds AbortSignal.timeout, so a relay that accepts but never responds can't hang flush() and block CLI exit.

Tests: EventStream return() cancellation (ai-autopilot); relay LRU eviction + publisher no-hang-on-stall (framework). ai-autopilot 340 + framework 152 green, including the real Docker serve-gate e2e.

Deferred (noted in #283, not this PR): SSE write backpressure; a per-run history cap (conflicts with full-history replay, needs a design call).

Two patch changesets (@gemstack/framework + @gemstack/ai-autopilot).