[Adityakk9031]

Summary

• MCP OAuth connections now request the scope named in the server's WWW-Authenticate: Bearer … challenge (scope attribute, RFC 6750 §3) when connecting. The challenge's scope takes precedence over the protected resource metadata's scopes_supported; the metadata list remains the fallback when the challenge names no scope, and the authorization-server metadata fallback is unchanged.

Fixes #2304.

Servers built on better-auth's MCP plugin answer a request to the resource with
WWW-Authenticate: Bearer resource_metadata="…", scope="mcp offline_access" while their
protected resource metadata correctly lists only mcp (RFC 9728 — offline_access is not a
scope on the resource). Executor previously took scopes only from the metadata, so it
authorized with scope=mcp, got no refresh token, and the connection showed Expired as
soon as the first access token lapsed.

Verification

• discoverProtectedResourceMetadata surfaces the challenge's scope attribute as
  challengeScope alongside the metadata it names (including when the challenge omits
  resource_metadata): new cases in packages/core/sdk/src/oauth-discovery.test.ts.
• oauth.start end-to-end on a better-auth-shaped fixture: the authorize URL requests
  mcp offline_access when the challenge carries scope, and still requests exactly the
  resource's scopes_supported (mcp) when the challenge names no scope: cases (m)/(n)
  in packages/core/sdk/src/oauth-scope-union.test.ts.
• Full packages/core/sdk suite green (64 files, 964 tests) and packages/core/api green
  (10 files, 134 tests); oxlint clean on the touched files; tsgo --noEmit exits 0 with
  only pre-existing diagnostics.