Fix remote stack overflow and uninitialized read in Content-Type/Content-Encoding parsing

[xroche]

Two memory-safety bugs in the HTTP response-header parser treathead(), both reachable from any crawl that fetches a URL from a hostile or compromised server.

First, a remote stack buffer overflow: Content-Type and Content-Encoding values are read with a width-less sscanf("%s") into an 1100-byte stack scratch buffer, with the length check happening only after the copy. The back_wait receive path hands treathead a line buffer of up to 2000 bytes (htsback.c rcvd[2048], binput capped at 2000), so a header value longer than 1099 non-whitespace bytes smashes the stack. Both scans are now bounded to the buffer (%1099s), matching the %31s/%255s idiom already used in the request-line parsers.

Second, the Content-Encoding branch ignored the sscanf return value, so an empty value (e.g. a bare Content-Encoding: header) left the scratch buffer uninitialized and then ran strlen() over it, an uninitialized read that can also over-read past the buffer. The Content-Type branch already guarded this case; this mirrors the guard.

Found via the P3-3 static-analysis baseline. The new -#test=headerlong self-test plus empty-value cases in 01_engine-header.test build the hostile inputs inside the handler (the CLI caps argument length) and abort on the pre-fix binary under AddressSanitizer (the overflow) and MemorySanitizer (the uninitialized read); both sanitizer CI jobs cover the regression.