Header parser accepts whitespace before colon, violating RFC 9112 §5.1

Split out from #56 (CVE-2022-31081), which only fixed the Content-Length multi-value case.

RFC 9112 §5.1 mandates:

No whitespace is allowed between the field name and colon. In the past, differences in the handling of such whitespace have led to security vulnerabilities in request routing and response handling. A server MUST reject, with a response status code of 400 (Bad Request), any received request message that contains whitespace between a header field name and colon.

HTTP::Daemon currently parses headers at lib/HTTP/Daemon.pm:166:

if (/^([^:\s]+)\s*:\s*(.*)/) {

The \s* before the colon accepts Host : localhost, Content-Length : 3, etc. — a direct MUST violation.

Security relevance

If HTTP::Daemon sits behind a frontend that drops or normalizes headers with whitespace before the colon, an attacker can send Content-Length : N\r\n that is ignored by the frontend but honored by HTTP::Daemon — a CL-vs-no-CL desync. RFC 9112 §5.1 explicitly notes that past handling differences "have led to security vulnerabilities in request routing and response handling."

Proposed fix

Tighten the parse to /^([^:\s]+):[ \t]*(.*)/ (also at Daemon.pm:264 in the chunked footer parser) and return 400 when the pre-colon character is whitespace.

@vanHoesel sketched this in #56 but held off, worried about pushing trimmed \s characters into HTTP::Headers downstream — that concern needs a second look.

Start in lib/HTTP/Daemon.pm at the header parser around lines 166 and 264, then review the related discussion in #56 about whitespace handling and HTTP::Headers. Verify that whitespace before the colon is rejected with a 400 response while valid header spacing remains accepted; run the repository's existing test suite and add regression coverage where appropriate.