Streaming: reproductions and baselines (blocks the byte-budget work)

Part of #4671 (step 0). Blocks step 4.

Why this exists as its own issue

The streaming design proposes bounding each connection by pending bytes, with the cap derived as a multiple of the largest legal frame. That derivation is currently in form only — there is no measured frame-size distribution, and no throughput claim in the design has been measured. Filing this separately is what stops the byte budget from being built on a guessed number.

Desired Behavior

Harnesses

• A delta-flood stress test (high token rate, slow/wedged consumer).
• A retry-injecting fake LLM, so retry × identity behaviour is testable without a provider.

Measurements

• Lock contention at step boundaries.
• EventLog.append cost against conversation length.
• Fan-out cost against connection count.
• Frame-size distribution — the input the byte budget is derived from.

Note

pi resyncs by re-sending the entire transcript against a 16 MiB frame cap. Our tool outputs won't survive that, which is why the design keeps paged replay rather than adopting pi's snapshot wholesale — but the frame-size numbers are what turn that from a hunch into a decision.

Acceptance Criteria

• A delta-flood stress harness exists (high token rate against a slow/wedged consumer).
• A retry-injecting fake LLM exists, so retry × identity behaviour is testable without a provider.
• Lock contention at step boundaries is measured and recorded.
• EventLog.append cost is measured against conversation length.
• Fan-out cost is measured against connection count.
• The frame-size distribution is measured and published, so the step-4 byte budget cites a number rather than a placeholder.