Fix response body decoding and header framing desync in CDP capture

[m4dni5]

Problem

Responses captured through Fetch interception reach the client with a broken body/length/encoding triple. Clients that reuse connections — browsers, chained proxies — see truncated scripts, cancelled stylesheets, and pages that hang. Single-request clients like curl hide the damage, so these bugs are easy to miss.

Root causes

Three independent bugs in the capture handlers in cdp.js:

1. Bodies decoded with the wrong encoding. Non-base64 Fetch.getResponseBody bodies are latin1-encoded text, but the code decodes them as utf8. Bytes >= 0x80 get mangled, changing the body length.

2. Headers describe a different body than the one sent. Fetch.getResponseBody returns the decompressed body, but the captured headers still carry the upstream compressed-size content-length and content-encoding. The body is therefore longer than the declared length, and the surplus bytes get parsed as the start of the next response on that connection, corrupting everything after it.

3. Optional CORS headers crash the preflight mock. The mocked preflight copies Access-Control-Request-Method/Headers from the request. Both are optional per the CORS spec; when absent, the emitted headers have value: undefined, and Chrome's CDP bindings reject the entire Fetch.fulfillRequest call, killing the fetch.

Fix

• Decode non-base64 bodies as latin1 (both capture handlers).
• Recompute content-length from the actual body and strip content-encoding.
• Default the preflight values; only emit Access-Control-Allow-Headers when the request asked for it.

Verification

• A large JS asset fetched direct vs. through the fixed proxy: byte-identical.
• content-length matches the delivered body on responses checked.
• A brotli-heavy, non-ASCII-heavy page behind an aggressive WAF renders fully through a chained intercepting proxy with no truncation or CDP errors in the logs.

[mandatoryprogrammer]

Thank you for the report! Merged a fix for it.