fix(cli): Guard baggage header against non-ASCII characters

[sentry]

This PR addresses CLI-3A8, where the Sentry CLI would crash with a TypeError from Node.js undici when attempting to set an HTTP baggage header containing non-ASCII characters.

Root Cause:
prepareHeaders() in packages/cli/src/lib/sentry-client.ts was passing the traceData.baggage value directly to headers.set(). If the Sentry SDK's getTraceData() produced a baggage string (e.g., from a release name) containing characters with code points greater than 255 (like Turkish 'ı' U+0131), undici's ByteString conversion would fail.

Solution:

1. Introduced a NON_HTTP_HEADER_CHAR_RE regex in sentry-client.ts to detect non-ASCII characters in the baggage header value.
2. Modified prepareHeaders() to check traceData.baggage against this regex. If non-ASCII characters are present, the baggage header is now gracefully omitted, preventing the TypeError.
3. Added a new test file, test/lib/sentry-client.baggage.mocked.test.ts, to cover cases with both valid ASCII and invalid non-ASCII baggage values, ensuring the guard functions as expected.

This ensures the CLI remains stable even when dealing with non-ASCII release names, while still forwarding distributed tracing information when possible.

Fixes CLI-3A8

_{@sentry <feedback>: Autofix iterates on these changes
@sentry stop iterating: Autofix stops iterating on this run}

_{This PR was automatically generated by Sentry. You can adjust this setting at any time.}

[sentry-junior]

Closing this one. The evidence points at the Authorization header, not baggage, and current main already fixes the real cause.

• Baggage can't contain non-ASCII here. getTraceData() builds baggage with dynamicSamplingContextToSentryBaggageHeader → objectToBaggageHeader, and that runs encodeURIComponent on every key and value (@sentry/core 10.63.0, utils/baggage.js). A release containing ı would be sent as %C4%B1. Also, the affected release in these events is 0.44.1, which is plain ASCII. The new tests mock getTraceData to return raw non-ASCII, which the SDK never produces.
• The failure matches Authorization: Bearer <token>. All 42 CLI-3A8 events are sourcemap upload on 0.44.1. There are two variants: U+0131 at index 32, and U+2022 (•) at index 7. Index 7 is the first character after Bearer , and • is a masked or pasted token character. A baggage value can't have that byte at index 7, because it always starts with a fixed ASCII sentry-… key.
• Already fixed on main. getsentry/cli#1638 (merged 2026-09-28, after 0.44.1) added normalizeAuthToken/formatAuthHeader in packages/cli/src/lib/auth-header.ts. They reject non-ASCII and whitespace in tokens with MalformedAuthTokenError before the Headers.set call, so this path no longer throws the undici TypeError.

Dropping baggage here would only hide a header that's already valid. If CLI-3A8 comes back on a release that includes #1638, that would be new evidence worth a fresh look.