[Sayan-]

Summary

Fast follow items from #462

• Expired requests could decrement a replacement capture's network-idle count, and ordinary requests could exceed the header-correlation limit. Bind request accounting to its original capture and enforce the 8,192-entry limit for both request-first and ExtraInfo-first admission.
• After saturation, new chains use base request headers until telemetry restarts or CDP reconnects. Already admitted chains continue collecting headers. This conservative fallback prevents a dropped early header event from shifting later headers onto the wrong redirect hop. Request, response, and failure events still publish in order. The response API and body limits are unchanged.

Document the existing five-minute request retention and the scope of the capacity limit: it bounds the header registry, not all in-flight requests or publishers.

Testing

• Regressions reproduce premature network-idle publication after capture replacement and growth beyond 8,192 entries, then pass with the fixes.
• Saturation coverage checks redirect order, success/failure delivery, base-header fallback, late headers for admitted chains, and cleanup. An ExtraInfo-first regression reproduces incorrect redirect header attribution and verifies recovery after capture reset.
• The race-enabled Chromium collector suite and related API/event suites pass locally. Full container image startup and installed bundled-extension tests were not rerun for this follow-up.

---

Note

^{Cursor Bugbot is generating a summary for commit c5859e2. Configure here.}