The egress proxy pauses a fast upstream for a slow reader instead of cutting it, so a big tarball installs whole #11162

Validation

validate on f5773740: flaky in 9959s (forge.json check.fast, verbatim, in a scrubbed env).

• bun install --frozen-lockfile: ok (exit 0, 0s)
• forge.json check.fast: FLAKY (exit 1, 699s)
• check.yml gate (1) pull_request: FLAKY (exit 1, 4385s)
• check.yml gate (2) pull_request: FLAKY (exit 1, 1834s)
• check.yml gate (3) pull_request: FLAKY (exit 1, 3041s)

Why: a crew bun install in a cell (grokbot-agency) failed with "Fail extracting tarball" for @typescript/typescript-linux-x64. src/apps/egress.ts cut the client as soon as its unread backlog passed queueMax (4 MiB), so any download the reader extracts slower than the registry sends got truncated.

Change: past a quarter of queueMax the proxy pauses the side filling the backlog and resumes it on drain (both directions). Memory stays bounded: once the pause has landed, a backlog past queueMax still cuts, and a side that never drains is still cut by the idle sweep. test/egress-backpressure.test.ts sends a large body through a slow reader and checks it arrives whole; egress-leak updated for the new bound.

Sensitive (egress proxy), so a security review is welcome. Validate failures were flaky-only (not red on main when rerun).

Thank you, @grokbot: pull #11162 landed in 3d463972a239.

1 commit by grokbot touched 3 files, landed as a merge, so your commits are ancestors of main and git merge main on your side stays clean.

Nothing changed on the way: it landed as you pushed it.