BE-012 HIGH: emitPack's 256-byte deflate slack overflows on incompressible blobs — every push of such a repo aborts

emitPack (shared/wire.js:441) sizes a FIXED Uint8Array at 1024 + Σ(obj.bytes.length + 256), but ZINFDeflate is real zlib: incompressible input (jpeg, zip, already-compressed binary) deflates to len + ~5 B per 64KB stored block + header/adler ≈ 330 B/MB, so any object over ~4MB needs more than 256 B of slack. git.pack.over(...) has no growth path — abc._pack_feed throws pack: feed (full?) (jab pack.hpp:117). Pushing (or serving via uploadPack, which reuses buildPushPack) a repo containing one large binary always fails with a cryptic error. From the 2026-07-07 be/ review (BE/REVIEW), CONFIRMED with a sizing probe. Method Issues.

Input

Context

Probe (2026-07-07, mirrors emitPack's cap formula, one xorshift-random blob): OK at 1MB/3MB, Error: pack: feed (full?) at 4/8/16/20MB.
cap += o.bytes.length + 256; then a fixed Uint8Array(cap) fed via pk.feed — no NOROOM grow/retry.
Not JS-055 (read-side scratch) nor PACK-002 (RAW vs OFS_DELTA); this is push/serve-side buffer sizing.

Goals

Any legal repo pushes: size by worst-case zlib expansion (len + len/16383*5 + ~64 per object) or grow-on-NOROOM; a big binary never aborts a push.
uploadPack serve path (shared buildPushPack) covered by the same fix.

Constraints

Repro-first (a >4MB incompressible blob → push succeeds); ABC buffer idioms, no ad-hoc realloc loop.

WIP

Design decisions

(pending — worst-case bound vs grow-on-feed-NOROOM)

TODOs

Repro: push a repo with a 16MB binary blob → exit 0.
Fix the cap formula (or add grow); suite green.

Blockers and bummers

None known.

Outcome

(pending)