Drop the authorization-server scopes_supported tier from scope selection.
That list is the server's catalog rather than what the resource needs,
so falling back to it could request every scope the server supports
when the protected resource metadata published an empty list. The
chain is now WWW-Authenticate scope, then PRM scopes_supported, then the
caller-configured scope, then omit; an empty published list falls
through instead of pinning an empty scope. AS metadata is still consulted
for whether offline_access may be added.
The provider now works on a copy of the caller's OAuthClientMetadata, so
the flow's scope selection no longer rewrites the caller's model and the
configured-scope snapshot cannot pick up another provider's discovered
scopes when metadata is reused across providers.
The OAuth client's scope-selection step overwrote the scope a caller
set on the provider on every 401, and when the server advertised no
scopes at all it left the token request with no scope. The configured
scope is now the last-resort tier after the WWW-Authenticate challenge
and the server's scopes_supported, matching the TypeScript SDK.
A source that yields no scopes (absent, null, or an empty list) now
falls through to the next tier instead of pinning an empty scope.
Max Isbey