Corpus position 4110, js/web/fetch/blob-oom.test.ts, currently times out after five minutes while consuming sustained CPU and roughly 700 MB RSS.
Root cause: the Home corpus Blob implementation eagerly converts each 64 MiB ArrayBuffer part through Array.from, then appends nine copies byte-by-byte in JavaScript. It does not model Bun synthetic allocation limits at the Blob/body-operation boundary, so the intended deterministic OOM cases become pathological materialization loops.
Port the real semantics without reducing upstream sizes or counts:
- preserve large Blob parts as lazy/segmented storage while retaining arbitrary byte content and slice behavior;
- enforce the synthetic allocation limit for Blob, Response, Request, and Bun.file text/JSON/bytes operations with Bun-compatible messages;
- keep arrayBuffer operations allowed where the upstream suite requires them;
- release segment references and temporary materializations deterministically;
- surface permanent structured allocation errors with operation, requested size, configured limit, original cause, and source-aware composed stacks;
- pin positions 4109 and 4110 in the permanent HTTP/web queue and update #66.
Current evidence: positions 4107 (11 pass), 4108 (1 pass), and 4109 (1 pass) are green. The first contiguous gap is 4110.