Base64-encode responses with non-identity Content-Encoding

[bensie]

Fixes silent corruption of compressed HTTP responses: responseBody() decided base64-vs-plaintext purely from Content-Type, so a handler behind gzip middleware (e.g. Content-Encoding: gzip with Content-Type: application/json) had its compressed bytes emitted as a literal JSON string. Found in a real production integration.

responseBody() now always base64-encodes when the response declares any non-identity Content-Encoding (handling multi-coding values like gzip, br and multiple header lines), which covers all four adapters since they funnel through it; the streaming path sends raw bytes and is unaffected. Content-Type sniffing is also skipped whenever Content-Encoding is set, matching net/http server behavior. Includes an end-to-end regression test that round-trips a gzip response through the FunctionURL adapter, plus unit coverage for the new isEncodedContent helper and responseBody encoding decisions.