perf: stream cached split PDF responses

[cragwolfe]

Cached split-PDF responses currently buffer the complete HTTP body before writing it to disk. This change streams cached responses to disk as they arrive, reducing memory use when several chunks finish together.

Body reads, cache writes and HTTP response cleanup remain inside the semaphore and retry boundary. Cancellation waits for owned I/O to finish. The response wrapper retains its transport iterator and joins one close task, so cleanup stays inside admission even when iteration stops after a failed write. Failed attempts remove incomplete files; only complete responses receive a cache path. The noncached response path is unchanged.

Observed results

• In a Linux test with 12 concurrent copies of a real 5.27 MB partition response, median peak RSS during caching fell from 205,622 to 87,746 KiB (a 57.3% reduction). Cache and recombination took about 11 ms longer, completing in under 0.5 seconds in both implementations.
• The full 382-page document produced exactly the same NDJSON bytes: 5,483 elements across all pages. Runtime was 598.340 seconds versus 595.694 seconds for the baseline, so this test shows no speed improvement. Peak RSS was 111,532 KiB with streaming versus 115,168 KiB for the baseline.
• 131 focused tests and targeted mypy type checks pass on the final source. Before the cleanup repair, 96 Linux fault controls passed, covering body failures, retries, cancellation, failed writes and cleanup.

This is a measured memory improvement for concurrent cached responses.

authored by codex

[cragwolfe]

Validation for exact head 81b3fb587b5adfd7756802dac7588212a337ea7c:

• All 19 GitHub checks/statuses pass. The 131 focused tests, targeted mypy and repository-configured pylint also pass.
• Four iterator-finalizer regressions fail before the repair and pass afterward. They cover both an equivalent stream and the actual HTTPX/HTTPcore transport/pool chain, with and without repeated SDK cancellation. Cleanup completes before admission is released, and a later request leaves the pool clean.
• A fresh full-context Oracle review returned SAFE TO MERGE for this exact source head, with no actionable Critical/High findings.

This is a source-safety verdict. The performance and document-parity measurements in the description precede the cleanup repair; they do not establish an ENG-1425 timeout fix. The PR remains draft pending the broader investigation; no merge or deployment.

authored by codex