fix: prevent malformed dual Content-Type on direct-transport token requests

[buptliuhs]

Summary

Direct (non-proxy) SSE and Streamable HTTP connections send a malformed dual Content-Type on the OAuth token request:

Content-Type: application/json, application/x-www-form-urlencoded

Strict authorization servers can't body-parse this, so token exchange and refresh fail (e.g. Keycloak: "Failed to parse media type..."). It surfaces on token refresh once an access token expires.

Root cause

For direct connections the Inspector passes a requestInit to the transport. The SDK wraps it with createFetchWithInit, which merges the base requestInit.headers with each request's own headers using a case-sensitive object spread.

The Inspector was injecting a capital Content-Type (and Accept) into requestInit. On the token request the SDK builds its headers with new Headers(...), which normalizes the key to lowercase content-type. Because the merge is case-sensitive, the capital Content-Type and the lowercase content-type both survive, and fetch then comma-joins them into the malformed value above.

Fix

Stop contributing content-type/accept via requestInit, and simplify the direct-transport custom fetch to a pass-through fetch(url, init). This is safe and complete because the SDK already sets those headers itself per request:

• MCP POST and the SSE GET stream — headers.set('content-type'/'accept', ...) on a Headers object (case-insensitive)
• the token request — sets its own Content-Type

Auth/custom headers (e.g. Authorization) still reach every request through the SDK's _commonHeaders(), which folds in requestInit.headers. The change also removes a pre-existing inconsistency where the SSE wrapper let the base headers clobber per-request headers while the Streamable HTTP wrapper did the opposite.

Tests

Added oauthHeaderMerge.test.ts, which drives the real SDK createFetchWithInit with the token request's exact shape:

• single Content-Type on the token request when requestInit carries only auth headers (the fix)
• a case demonstrating that leaving a Content-Type in requestInit re-introduces the dual header (the bug)

All existing useConnection tests (46) still pass; lint and prettier clean.

Also verified end-to-end against a live OAuth-protected MCP server over an ngrok tunnel: the token request now goes out with a single Content-Type: application/x-www-form-urlencoded, and token exchange/refresh succeed.

Scope

Affects direct SSE / Streamable HTTP connections only (proxy connections were unaffected).

[buptliuhs]

@cliffhall can you please review? thanks!