perf(collect): stop buffering every response body just to count bytes

[JonasJesus42]

Problem

responseToEntry() in src/engine/collect.ts called safeBodySize() → resp.body() for every response of every page, just to record byteLength for the network waterfall — even though content-length was already parsed as the fallback.

resp.body() forces Chromium to materialize the entire response body (images, fonts, video, …) and copy it into the Node heap. Done for every request, on every page, across up to 4 concurrent BrowserContexts on image-heavy commerce pages, this was one of the largest drivers of resident memory — contributing to the OOM pressure that SIGKILLs sibling processes (exit 137).

Fix

• Prefer the content-length header (which is what a byte waterfall wants anyway — transfer size).
• Only fall back to resp.body() for small text resources (document/script/xhr/fetch) and only when the header is absent.
• Never buffer binary assets (image/media/font/stylesheet) just to count bytes.

Also a speed win: far less body I/O per page.

Verification

• bun run check (tsc) passes.
• No tests depend on the previous body-buffering behavior.

Part of the memory-pressure / OOM series (see #173).

🤖 Generated with Claude Code

---

Summary by cubic

Stop buffering response bodies in collect to compute transfer size. We now use content-length when present and only read bodies for small text responses, cutting memory use and speeding up runs.

• Refactors
  • Prefer content-length in responseToEntry() for waterfall transfer size.
  • Only read the body when the header is missing and the resource is small text (document/script/xhr/fetch); skip binary assets.
  • Introduced isSmallTextResource() to gate the fallback.

^{Written for commit a27cd91. Summary will update on new commits.}