Large OmO status replay blocks bridge health and Web UI requests #2360

Problem

After startup, the web server can stop answering all HTTP/WebSocket work while it
reconstructs OmO agent status from large session transcripts. Even
GET /api/health?scope=bridge stalls despite needing no agent transcript.

Observed on macOS with Bun:

• TCP connections to the bridge completed in less than 1 ms.
• Bridge-health requests received zero bytes and timed out after 8-12 seconds.
• During the stall, the server held an approximately 160 MB OmO JSONL transcript open.

No private transcript is needed to reproduce this.

Code path on main

Confirmed at e604183814d0293b51c192122c256e4c46288fb5:

1. server/core/status.ts wires the OmO/GJC status trackers into snapshots and
   periodic status polling.
2. server/omo-status.ts replays a newly discovered session from byte zero.
3. server/omo-records.ts reads 256 KiB chunks with readSync, then projects
   strings character by character, but never yields between chunks.

The reader bounds retained string data, not uninterrupted event-loop work.
Multiple panes and long records amplify the delay. GJC uses the same tracker.

Reproduction and expected behavior

A regression fixture creates its own temporary state directory, listens on port
0, and replays a synthetic transcript containing a 16 MiB tool-result record.
After the first replay record is consumed, it requests the real
/api/health?scope=bridge endpoint. The health response must arrive before replay
completes. There are no fixed sleeps or real user sessions in the fixture.

The fix should yield within long records as well as between records, preserve the
existing question/completion/background-task semantics, and prevent an obsolete
replay from publishing after its pane changes session or agent.