fix: decode header values per-ecosystem (Python/JS) and expose raw header bytes

[Pijukatel]

Context

Response header values were decoded as ISO-8859-1 (b as char, introduced in #434 to stop
non-ASCII header bytes from crashing Node / emptying Python, #430). That corrupts the common case
of UTF-8 header values (e.g. Content-Disposition: filename="naïve.pdf") into mojibake
(#479). The two positions genuinely conflict: a byte sequence can't be decoded as both ISO-8859-1
and UTF-8, and the "right" answer differs by ecosystem.

How

Rather than force one behavior on both bindings, each binding now follows the reference client
it emulates, and both gain a way to read the exact header bytes for signature/HMAC use:

• Python decodes header values UTF-8-first with an ISO-8859-1 fallback (httpx semantics),
  via a shared decode_header_value helper in the core crate. This fixes Header values decoded with 'b as char' (Latin-1) corrupt UTF-8 header values into mojibake #479 for Python while
  keeping fix: decode non-ASCII response header values as ISO-8859-1 #434's latin-1 case (a lone 0xE4 → ä) and Crashes on non-ASCII header values #430's never-crash/never-empty guarantee
  (no U+FFFD).

• JavaScript keeps strict ISO-8859-1 (Fetch semantics), so its string values stay
  byte-recoverable via Buffer.from(v, 'latin1').

• Both expose the untouched header value bytes:

  • Python Response.raw_headers → list[tuple[bytes, bytes]]
  • JS response.rawHeaders → Array<[string, Uint8Array]> (declared in index.d.ts, preserved
    across clone())

  Header values are exact; names are lowercased and original wire order is not preserved (a
  reqwest::HeaderMap limitation); duplicate values for a name are kept.

Net effect on #479

• Python: fully fixed — UTF-8 header values decode correctly.
• JavaScript: string values remain ISO-8859-1 by design (Fetch parity, byte-recoverable);
  callers needing the decoded UTF-8 value read rawHeaders and decode with TextDecoder.

Consistency with ecosystem

impit's two bindings each emulate a reference client, so header decoding is deliberately
asymmetric — and each side matches its reference exactly. Both bindings additionally expose
the raw header bytes, following the byte-access pattern each ecosystem already relies on.

Python — matches httpx (which impit-python implements)

impit-python advertises the httpx interface ("drop-in replacement for httpx.AsyncClient"), and
httpx decodes header values UTF-8-first with an ISO-8859-1 fallback — exactly what this PR
does via the shared decode_header_value helper:

• httpx Headers.encoding tries ascii, then utf-8, then falls back to iso-8859-1:
  httpx/_models.py @ v0.28.1, encoding property
  — "Header encoding is mandated as ascii, but we allow fallbacks to utf-8 or iso-8859-1."
• httpx exposes raw bytes via Headers.raw: list[tuple[bytes, bytes]]:
  httpx/_models.py @ v0.28.1, raw property.
  Our new Response.raw_headers returns the same list[tuple[bytes, bytes]] shape.

So Python callers get the same decoded strings and a raw-bytes escape hatch like httpx's.

JavaScript — matches the Fetch API / undici (which impit-node implements)

impit-node is "API-compatible with the Fetch API Response". In Fetch, header values are a
byte sequence exposed to JS as a ByteString, i.e. via isomorphic decode — each byte
0x00–0xFF maps to the code point of equal value (ISO-8859-1). This PR keeps impit-node on that
exact behavior (b as char):

• Fetch Standard: a header value is a byte sequence,
  and the Headers interface types names/values as
  ByteString (ByteString get(ByteString name)).
• WebIDL ByteString is the isomorphic
  (byte ↔ code-point) mapping — i.e. ISO-8859-1.
• undici (Node's fetch) implements exactly this: nodejs/undici#1560 "ByteString checks &
  conversion in Headers" and
  #1317 confirm header values are handled as
  Latin-1 ByteStrings.
• Node's core http parser likewise decodes header values as latin1/binary
  (nodejs/node#17390,
  #58240); axios inherits this because its
  Node adapter reads http.IncomingMessage headers and its browser adapter reads
  XMLHttpRequest/Fetch headers.

Because ISO-8859-1 is isomorphic, the JS string stays byte-recoverable — the standard Fetch
workaround Buffer.from(value, 'latin1') (or Uint8Array.from(value, c => c.charCodeAt(0)) in
the browser) reproduces the exact wire bytes, so a UTF-8 header can be recovered with
Buffer.from(value, 'latin1').toString('utf8').

Tests

• Core: unit tests for decode_header_value (ASCII, UTF-8, invalid-UTF-8 latin-1 fallback,
  no-replacement-char round-trip, empty).
• JS: existing latin-1 regression test kept; new test asserting the string stays ISO-8859-1, that
  rawHeaders yields the exact UTF-8 bytes, that the latin-1 string round-trips to those bytes,
  and that rawHeaders survives clone().
• Python: raw_headers shape/bytes via the constructor, plus a wire-level integration test (raw
  socket) covering the real fetch path — httpx-style UTF-8 decode, latin-1 fallback, and exact
  raw_headers bytes.

[Pijukatel]

Just for the convenience of using the /devforge