[user-github-me]

fetch decodes content-encoded responses while retaining their compressed Content-Length. Cloud downloads compared the decoded bytes against that header and rejected valid gzip, deflate, and Brotli responses as truncated.

Only use Content-Length for unencoded or identity responses. Content-encoded downloads report their received byte count with an unknown total; fetch and the stream pipeline continue to surface transfer errors and cancellation. Preserve atomic replacement and the existing output on failure.

Validation: 119 cloud/client and cloud-command tests pass, including real HTTP coverage for gzip, x-gzip, mixed-case gzip, deflate, Brotli, stacked compression, identity, and an unknown coding. Six compressed-response regressions fail on current main. Interrupted and cancelled gzip transfers preserve the previous output; identity and unencoded truncation checks still pass. CLI build and typecheck, repository lint, formatting, and test reachability pass. A separate Node 22/local-HTTP probe reproduces the original 1,920-versus-51-byte false truncation and verifies the corrected bytes on disk.

Related: #3944 addresses a separate writer-close/cleanup race; this PR leaves that implementation to its existing author.

[jrusso1020]

Thanks, this is a real fetch quirk, but neither caller currently gets a response with both Content-Encoding and Content-Length: render outputs are unencoded S3 objects, and the model host sends gzip without a length. Since it isn't reachable today and #3944 is already open on the same file, we'll hold off rather than add the churn. — Rames