The net layer never decoded a response's Content-Encoding, so origins that serve pre-compressed objects (e.g. Google Cloud Storage, which replies with `Content-Encoding: gzip` regardless of the client's Accept-Encoding) handed raw gzip bytes to consumers. On tradera.com (a Next.js app whose chunks are GCS-hosted) this made ~17 `_next/static/chunks/*.js` files fail to parse with `unexpected character '\u{1f}'` (the gzip magic byte), blocking hydration. Decode Content-Encoding after transfer decoding, in both the HTTP/1.1 (`http::parse_response`) and HTTP/2 (`client::execute_h2_request`) paths, since a Content-Encoding is a property of the representation and must be decoded regardless of Accept-Encoding. Reuse the existing pure-Rust we-image decoders: - gzip/x-gzip -> new `we_image::gzip::gunzip` one-shot helper - deflate -> zlib_decompress, falling back to raw inflate - identity / empty -> no-op - unknown codings (e.g. br, never advertised) -> passed through untouched Comma-separated codings are undone in reverse; corrupt streams surface the new `HttpError::ContentDecoding`. Verified the tradera render now emits 0 gzip-magic parse errors. Discovered while investigating isu issue 344 (tradera), which stays open for its remaining downstream ad-library JS gaps. Tests: gunzip round-trip/truncation (we-image); gzip/identity/unknown/corrupt decode + end-to-end parse_response_decodes_gzip_body (we-net). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>