fix(internal): lowercase header names with locale-pinned en-US rule

[tsushanth]

Why

Closes #1928.

`String.prototype.toLowerCase()` applies the host locale to certain Unicode mappings. On a Turkish process locale the uppercase `I` in `OpenAI-Organization` becomes the dotless `ı`, producing `openaı-organization`, which fails Node's HTTP token validation (`TypeError: Header name must be a valid HTTP token`) and tears down the request before it is ever sent. The reporter traced this all the way to `src/internal/headers.ts:77` and verified the workaround.

I also looked at the other call sites where this SDK lowercases header names for matching, and found the redactor in `src/internal/utils/log.ts` does the same thing on the same hot path. There the consequence is more subtle but more serious: an `Authorization` header arriving as `authorızatıon` after the Turkish casing rule never matches the redaction list, so the bearer token would be written verbatim into the logged request representation. Worth fixing in the same PR since it's the same root cause and a security-shaped exposure.

What

• `src/internal/headers.ts`: `name.toLowerCase()` → `name.toLocaleLowerCase('en-US')` in `buildHeaders`, with a comment linking back to this issue.
• `src/internal/utils/log.ts`: pre-compute `lowerName = name.toLocaleLowerCase('en-US')` once and use that for the redaction comparisons. (Also removes the five repeated `.toLowerCase()` calls.) Same comment + issue link.

HTTP header names are RFC 9110 ASCII so anchoring on en-US is the correct invariant.

Tests

`tests/buildHeaders.test.ts` — new `lowercases header names with ASCII rules even under a Turkish process locale` test. Monkey-patches `String.prototype.toLowerCase` for the duration of the test to mimic the Turkish casing rule (`I` → `ı`), then verifies the canonical key in the resulting `NullableHeaders` is `openai-organization` and ASCII-only.

`yarn jest tests/buildHeaders.test.ts` → 11 passed. `yarn jest tests/log.test.ts` → 4 passed.

Stainless note

This change is in `src/internal/`, which is generated by Stainless. I considered whether the right path was to wait for the upstream codegen change. Felt it was worth proposing the diff directly anyway because (a) the bug currently corrupts requests / leaks credentials in production on a non-trivial install base, (b) the fix is mechanical and easy to mirror in the generator template, and (c) precedent from openai/anthropic SDK repos suggests external PRs to generated paths are merged when correctness-shaped.

Happy to defer to whatever process you'd prefer for landing this — let me know if you'd like the change in a different form.

[tsushanth]

Rebased onto current upstream.

[tsushanth]

Rebased onto current upstream.