fix(mcp): authenticate servers with public discovery - #55139

I read this against the v1 head (3a48c08) and the 1.32.0 SDK sources. The core change looks right to me:

• McpOAuthPendingProvider.tokens() only returns staged tokens, so once the server advertises authorization-server metadata, the standalone auth() call in startAuth always ends in REDIRECT. That means an explicit login really does go through the browser instead of being satisfied by a public initialize, which is exactly what #55138 asks for. The mcp auth CLI already asks for confirmation before re-authenticating, so this doesn't add surprise prompts.
• The callTool proxy covers the only tool-invocation path (McpCatalog.convertTool → client.callTool). The s.clients[name] === client and status === "connected" guards keep a stale client from flipping a server that has already been replaced, and the rejection is rethrown rather than replayed.
• Passing fetchFn from createFetchWithInit(undefined, headers) matches what the transport hands to auth() itself, and auth.js still wraps discovery, token and registration fetches in fetchWithinOrigin. So I don't see a new cross-origin header exposure here.

One regression I think is worth handling before merge: discoverOAuthServerInfo now runs unconditionally, before connect. It swallows protected-resource-metadata errors, but discoverAuthorizationServerMetadata throws on any 5xx (HTTP 5xx trying to load OAuth metadata from …, around client/auth.js:713-719 in 1.32.0). Before this PR, discovery only happened after a 401. So take a remote server that doesn't use OAuth at all (public, or static-header auth with oauth left at its default) and sits behind a gateway or catch-all route that answers unknown /.well-known/* paths with 500/502/503. opencode mcp auth <name> (or the in-app authenticate) used to connect. Now it hits Effect.die with a metadata error. The new tests only stub 404 for well-known paths, so they don't catch this.

A small fix that keeps the intended behavior is to treat a failed discovery the same as "no metadata" and fall through to the existing connect path. If the server really does need OAuth, the transport's own 401 handling still captures the redirect, with the WWW-Authenticate hints:

const discovery = await discoverOAuthServerInfo(url, { fetchFn }).catch(() => undefined)
if (
  discovery?.authorizationServerMetadata &&
  (await auth(authProvider, { serverUrl: url, scope: oauthConfig?.scope, fetchFn })) !== "AUTHORIZED"
) {
  throw new UnauthorizedError()
}

A regression test with the stub returning 503 for /.well-known/oauth-authorization-server and /.well-known/openid-configuration, expecting connected, would pin it down.

Non-blocking: auth() repeats the PRM and AS discovery that discoverOAuthServerInfo just did, so each explicit login makes those requests twice. If you want to avoid that, passing resourceMetadataUrl from discovery.resourceMetadata (or just letting auth() do the discovery and checking its result) would remove the duplicate round trips.

Re-checked 18527bd against my earlier note. The .catch(() => undefined) on discoverOAuthServerInfo plus the discovery?. guard resolves it: a 5xx from the AS or OpenID well-known now falls through to the normal connect path instead of failing mcp auth, and an OAuth-enabled server with working metadata still goes through the explicit auth() call. The two new 503 regressions (OAuth metadata, and OpenID metadata with a static Authorization header) cover exactly the gateway case, and asserting authorizeCalls() === 0 is a good guard against an accidental browser open.

One small behavioral note, not blocking: the catch also swallows transient network errors on an OAuth-protected server, so mcp auth would connect, get a 401, and land in needs_auth rather than surfacing the discovery error. That seems like the right trade for this backport.

Looks good to me.