LGTM. The recovery path is well-targeted at the specific request-smuggling case the upstream test exercises:

• Upstream parallel/test-http-client-reject-chunked-with-content-length.js sends a response with both Content-Length: 1 and Transfer-Encoding: chunked and asserts err.code === 'HPE_INVALID_TRANSFER_ENCODING' plus err.message matching /^Parse Error/.
• prepareError now checks err.code === "HPE_ERROR" (the generic code the Rust binding returns), runs two ^…[ \t]*: regexes against the latin1-decoded header section of rawPacket, and on a hit overwrites err.code = "HPE_INVALID_TRANSFER_ENCODING" and err.reason. The subsequent err.message = "Parse Error: ${err.reason}" line satisfies the test's regex too.
• headerSegmentLatin1 correctly bounds the CRLF/CRLF scan with i + 3 < len so the last access (view[i+3]) reads view[len-1]. Falls back to scanning the whole packet when the terminator isn't found, which is fine because the regexes either match or don't.
• The two regexes (^content-length[ \\t]*: and ^transfer-encoding[ \\t]*:[^\\r\\n]*\\bchunked\\b) use m for multi-line matching and i for case-insensitive — \\bchunked\\b correctly distinguishes from chunked-encoding-style values. Header folding (continuation lines starting with whitespace) isn't handled, but that's deprecated in HTTP/1.1 so unlikely to matter.
• New primordials (StringFromCharCode, TypedArrayPrototypeGet{Buffer,ByteLength,ByteOffset}) are imported correctly. for (let i = 0; i < end; i++) out += StringFromCharCode(view[i]) is O(n²) on string concat but the header section is small (< a few KB) and this only runs on parse errors.

CI is 0 failures, 18 pending.