undici vulnerable to downstream response desynchronization via retry interceptor

### Impact Undici's `interceptors.retry()` can deliver a response whose body length does not match the `Content-Length` header exposed to the application after a retry or resume of a partial response. Applications that use `interceptors.retry()` and forward upstream response headers and bodies downstream, for example proxy or gateway applications, may emit an invalid HTTP response with a stale `Content-Length` header. This can lead to downstream response desynchronization, connection hangs, or response corruption in clients or intermediaries that rely on the forwarded framing metadata. A malicious or faulty upstream can respond to a range request with a `206 Partial Content` response such as: ```http Content-Range: bytes 0-99/300 Content-Length: 300 ``` and then send only 99 bytes before closing the socket. `interceptors.retry()` can then retry with `Range: bytes=99-99`, receive the final byte, and deliver a 100-byte body to the application while the response headers still contain `Content-Length: 300` from the first response. The bug requires `interceptors.retry()` to be enabled, an upstream that returns a partial response with a mismatched framing header, and a downstream forwarder that does not remove or recalculate `Content-Length`. ### Patches Patched in undici v6.28.0, v7.29.0, and v8.9.0. Users should upgrade to one of these versions or later. ### Workarounds - Disable `interceptors.retry()` for untrusted upstreams. - Remove or recalculate `Content-Length` before forwarding a response body assembled or transformed by Undici.

Quoted source text, attributed separately from HOL analysis.