/api/fetch relays the dropped body's framing headers when it refuses an oversized error response #2771

Found during the v2.12.0 release smoke (#2764).

Problem

When /api/fetch drops an oversized upstream body for an error status, it relays the status with its headers and no body. That part is deliberate: the status is what OAuth discovery acts on. The relayed headers, however, are the upstream's verbatim, including the framing headers that described the dropped body:

upstream: 404, 5 MiB body
/api/fetch → {"ok":false,"status":404,"statusText":"Not Found","headers":{…"content-length":"5242880"…}}   (no body)
upstream: 404, 5 MiB chunked
/api/fetch → {…"headers":{…"transfer-encoding":"chunked"}}                                             (no body)

createRemoteFetch rebuilds the browser-side Response from those headers with a null body. The result is a response that reports content-length: 5242880 and has an empty body. Nothing in the SDK reads the length, so nothing breaks today, but it misdescribes the response to any consumer that does read it.

Expected

On the oversize-error path only, the relayed headers omit the headers that described the dropped body: content-length, transfer-encoding and content-encoding. Every other header is relayed as before. The success path (502) and normally relayed bodies are unchanged.

Scope

This fix covers only the oversize-error path. Whether normally relayed bodies should drop content-encoding/content-length after undici decodes them is a separate, pre-existing question and is not part of this issue.