malformed response bodies can degrade into false successful empty fetches

[chaliy]

Summary

When read_body_with_timeout() encounters a body-stream error before any bytes have been read, it returns (empty, false) instead of surfacing an error or at least marking the response as truncated.

Impact

A hostile origin can send a malformed chunked/body stream and cause FetchKit to return a successful 200 OK response with empty content. That suppresses the real failure mode and drives agent callers down the success path. The same helper is used by fetch_to_file, so it can also create misleading zero-byte files.

Confirmed locally with a malformed chunked response:

• status code returned as 200
• content returned as empty string
• truncated was None
• no error surfaced to the caller

Affected code

• crates/fetchkit/src/fetchers/default.rs:650-653

Repro outline

1. Start a local HTTP server
2. Return HTTP/1.1 200 OK with Transfer-Encoding: chunked
3. Send an invalid chunk header (for example ZZ) instead of a valid hex chunk size
4. Call FetchKit against that endpoint
5. Observe a successful empty response instead of an error

Expected fix

A body-stream protocol error with zero bytes read should not be treated as a clean success.