Correct repeated Transfer-Encoding and Content-Length response framing

[hdbjeff]

Follow-up from the post-merge review of #23.

Problem

The new HTTP/1 response pump uses header_field, which returns only the first field with a given name. Response framing therefore does not correctly handle repeated Transfer-Encoding or Content-Length fields.

Examples:

• Transfer-Encoding: gzip followed by Transfer-Encoding: chunked is validly terminated by chunked framing, but the proxy sees only the first field and treats the response as read-to-close.
• Conflicting Content-Length fields are not rejected.
• A malformed first Content-Length becomes indistinguishable from no framing and is treated as read-to-close.

On keep-alive connections this can consume subsequent responses as part of the preceding body, break request/response correspondence, or stall until the upstream closes.

Location

• src/http_proxy.rs: header_field, content_length, is_transfer_encoding_chunked, and response_body
• Response pump introduced by PROXY protocol v2 + downstream JA3/JA4 fingerprint forwarding #23.

Acceptance criteria

• Combine all Transfer-Encoding field values in wire order and frame as chunked only when the final coding is chunked.
• Validate every Content-Length occurrence, including comma-list normalization where supported; reject conflicting or malformed values.
• Define and test behavior when Transfer-Encoding and Content-Length coexist in a response.
• Add response-side tests for:
  • repeated TE ending in chunked;
  • repeated TE not ending in chunked;
  • identical repeated CL;
  • conflicting CL;
  • malformed CL;
  • each case followed by another keep-alive response to verify correspondence.