[Dylan-M]

Proposed Change

Add deterministic replay mode in addition to the normal random read mode. In this mode (generator.filegen.mode: replay), Blitz sends every line of a capture file once, in order, then ends the run. Lines without timestamp directives replay byte for byte. There is also a new generator.filegen.seed that makes random-mode line picks repeatable.

count.Tracker.Acquire now returns a Permit that the generator settles with Commit or Release. Embedders calling count.Tracker directly need the new API.

Checklist

• Changes are tested
• CI has passed

[Caleb-Hurshman]

A couple things that Claude flagged:

1. Replay isn't byte-for-byte. Every replay goes through processTimestamps, which means percent-encoded URLs will get interpreted like GET /caf%C3%A9 -> /caf%C3Friday9
2. A failed record is retried without a cap, so a finite run may never end.
   • Hostmetrics is especially risky. If one scraper fails, the whole scrape is released
3. Seeding doesn't make random mode repeatable. A retry after a failed write makes a new rng.Intn, shifting every later pick

[Caleb-Hurshman]

Pretty cool, see my comment above for stuff that needs tweaking

[Dylan-M]

The byte-for-byte limit is documented in filegen.md. Replay's retry cap is in #345, which drops a line after three failed retries. A run whose destination keeps rejecting one hostmetrics scraper still waits, since the count is of delivered records. That rejection now logs at error, so the stall shows up. The seed docs now say a failed send uses up a pick, so delivered lines only repeat when every send succeeds.