perf: stream cached split PDF responses - #357

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