Transfer-Encoding accepts non-OWS whitespace before "chunked" (TE.CL smuggling vector)

Split out from #56 / CVE-2022-31081 (POC #7).

Per RFC 9110 §5.6.3:

OWS = *( SP / HTAB )

Only SP and HTAB are permitted as optional whitespace around a field-line value.

HTTP::Daemon's header-value parse at lib/HTTP/Daemon.pm:166 strips \s* after the colon — which in Perl includes TAB, form feed (\x0c), and vertical tab (\x0b). So Transfer-Encoding: \x0cchunked normalizes to chunked and triggers chunked decoding at lib/HTTP/Daemon.pm:212:

if ($tr_enc && lc($tr_enc) eq 'chunked') {

Per RFC 9112 §6.1, Transfer-Encoding = #transfer-coding — a comma-separated list of bare tokens with no internal whitespace. RFC 9112 §6.1 further states:

A server that receives a request message with a transfer coding it does not understand SHOULD respond with 501 (Not Implemented).

Security relevance

This is the canonical TE.CL smuggling vector documented in PortSwigger's HTTP Desync Attacks: Request Smuggling Reborn. A frontend that treats Transfer-Encoding: \x0cchunked as unrecognized (and falls back to Content-Length framing) while HTTP::Daemon decodes it as chunked produces a desync — attacker bytes beyond the chunked body are read by the frontend as the start of the next pipelined request.

Proposed fix

1. Tighten header-value extraction to use [ \t]* rather than \s* (overlaps with #84).
2. Validate the parsed Transfer-Encoding value against the RFC 9112 §6.1 grammar before matching chunked at Daemon.pm:212 — i.e. parse it as a comma-separated list of transfer-coding tokens and check exact match (case-insensitive) on each, rather than lc($tr_enc) eq 'chunked' on the raw value.

Start with the header-value parsing at lib/HTTP/Daemon.pm:166 and the Transfer-Encoding handling at lib/HTTP/Daemon.pm:212, then compare both paths with RFC 9110 §5.6.3 and RFC 9112 §6.1. Done means non-OWS whitespace is not accepted as equivalent to SP or HTAB, and Transfer-Encoding is validated as a comma-separated list before chunked decoding is selected.