fix: use the auth provider's current token instead of a connect-time snapshot

[buptliuhs]

Summary

After a successful OAuth token refresh, direct (non-proxy) connections keep sending the old access token, so the session enters a 401 loop it can't recover from. Once the access token expires:

1. POST /mcp returns 401, the SDK refreshes, POST /token (grant_type=refresh_token) returns 200, and the provider stores the new token.
2. The retried POST /mcp still carries the old Authorization: Bearer …, gets another 401.
3. The SDK's circuit breaker throws "Server returned 401 after successful authentication".

This is rarely hit with a long token TTL, but a short TTL breaks the session at first expiry.

Root cause

When relying on OAuth, useConnection read the access token from the provider once at connection setup and baked Authorization: Bearer <token> into requestInit.headers.

The transports already receive that same provider as their authProvider, so the SDK adds a fresh Authorization from it on every request (and refreshes it on 401). But the SDK's _commonHeaders() spreads requestInit.headers after the provider token:

const headers = {};
if (this._authProvider) {
  const tokens = await this._authProvider.tokens();      // fresh token (post-refresh)
  headers['Authorization'] = `Bearer ${tokens.access_token}`;
}
const extraHeaders = normalizeHeaders(this._requestInit?.headers); // connect-time snapshot
return new Headers({ ...headers, ...extraHeaders });     // ← snapshot wins

So the connect-time snapshot always shadows the provider's current token. The provider does store the refreshed token (saveTokens/tokens() round-trip the same sessionStorage key) — it just never gets used.

Fix

Stop snapshotting the OAuth token into requestInit. The provider is the single, always-current source of the token, and the SDK injects and refreshes it per request. A user-supplied static Authorization header still flows through the custom-headers path and intentionally overrides the provider.

Tests

• Updated the test that asserted the old baking behavior to assert the token is no longer baked into requestInit and that authProvider is set.
• Added direct SSE / Streamable HTTP tests covering the same.
• The existing "preserves server Authorization header" test still passes, confirming static user-supplied tokens are unaffected.

All useConnection tests pass; lint and prettier clean; client build compiles.

Scope

Independent of the malformed-Content-Type fix. Affects connections that use the SDK's OAuth authProvider.

[buptliuhs]

@cliffhall can you please review? thanks!