fix: reject control characters in header names and values, harden transport header adaptation

[OmarAlJarrah]

Problem

Headers.Builder validated header values for CR/LF but never validated header names. Name handling only lower-cased and trimmed surrounding whitespace, so an interior \r, \n, NUL, or other control character passed through the model layer intact.

Downstream, the two reference transports then diverged on such a name:

• OkHttp called addHeader(name, value) with no guard. OkHttp rejects an illegal name with an unchecked IllegalArgumentException, which escaped execute() despite its @Throws(IOException) contract and bypassed the transport's IOException handling / retry pipeline.
• JDK wrapped header(name, value) in try/catch(IllegalArgumentException) and silently dropped the offending header.

So the same SDK-level request produced two different observable outcomes depending on transport. It was also a header-injection surface for attacker-controlled names.

Change

• Add validateName beside validateValues in Headers.Builder, invoked from the String-based add/set before the name is stored. It rejects blank names and any character in the C0 control range (0x00–0x1F, which covers CR/LF/NUL) or DEL (0x7F).
• The typed HttpHeaderName overloads carry pre-validated token names, so they are unaffected.
• Correct the OkHttp and JDK transport-adapter comments that previously claimed names were validated upstream; they now describe the actual name and value guarantees.

The policy deliberately stops at control characters rather than RFC 7230's full tchar allow-list, mirroring the conservative CR/LF-only stance already used for values: it closes the splitting/injection surface (control characters are illegal in every transport) without rejecting non-ASCII names that some transports accept.

Tests

Added coverage in HeadersTest for CR, LF, CRLF, NUL, and DEL injection in names via both add and set (single- and list-value overloads), a blank-name rejection, a message-naming check, and an accepted-name case (including whitespace trimming).

Gated build (scoped, --no-daemon)

• ./gradlew :sdk-core:test :sdk-core:ktlintCheck :sdk-core:detekt :sdk-core:apiCheck — passed
• ./gradlew :sdk-transport-okhttp:compileKotlin :sdk-transport-okhttp:ktlintCheck :sdk-transport-okhttp:detekt :sdk-transport-jdkhttp:compileKotlin :sdk-transport-jdkhttp:ktlintCheck — passed (detekt is not run on the JDK 11 module)

No public API change (validateName is private), so apiCheck passes with no apiDump.

Closes #114

Update: typed-API validation, transport hardening, and message escaping

Follow-up addressing gaps in the original change:

• The typed header API is now validated too. The name check moved into a shared
  requireValidHeaderName invoked by both Headers.Builder and HttpHeaderName.fromString.
  Previously fromString performed no name validation, so the typed API could intern a
  control-character name and hand it to a transport — the same splitting surface the String API
  closes. The validator runs on the trimmed name (surrounding HTTP whitespace is stripped and
  harmless; an interior C0/DEL byte is rejected) and rejects blank names; fromString("") and a
  control-character name are now rejected rather than interned.
• The OkHttp adapter no longer leaks an unchecked exception. OkHttp's addHeader rejects any
  non-printable-ASCII byte, so a model-valid non-ASCII (for example UTF-8) name or value would throw
  an IllegalArgumentException out of the synchronous execute(), past its @Throws(IOException)
  contract. The adapter now catches it per header and drops the offending entry, mirroring the JDK
  transport adapter. The adapter comments that claimed addHeader never throws are corrected.
• Error-message escaping. The rejection message renders control characters as a unicode escape
  instead of echoing the raw bytes.

Added tests for the typed-API rejection, the C0/DEL predicate boundary, the message escaping, and the
OkHttp and JDK drop-not-throw paths (sync and async). No public API change.

Behavioral changes

Pre-1.0 alpha, so these are acceptable, but worth calling out for reviewers and consumers:

• HttpHeaderName.fromString("") and fromString(" ") now throw IllegalArgumentException instead of interning an empty header name.
• Header value validation broadened from CR/LF-only to the full C0 control range (except horizontal tab) plus DEL. A value containing, for example, a vertical tab or form feed that previously passed is now rejected.

Follow-ups

Two design questions deliberately left out of scope here are tracked separately:

• Header model permits non-ASCII names/values that both reference transports silently drop #167 — whether the model layer should also reject non-ASCII names/values, which both reference transports drop today.
• Transport header-drop logs at WARN per request may be noisy for repeated non-encodable headers #168 — whether the per-request WARN log for transport-dropped headers is too noisy.