Specified ClientOAuthOptions.Scopes are ignored

[halllo]

Describe the bug
My client specifies Scopes via the ClientOAuthOptions. The xml comment states

"When specified, these scopes will be used instead of the scopes advertised by the protected resource.".

However it always uses the scopes from the PRM for the authorize URL. It only falls back to the specified scopes, when the PRM does not provide any scopes. I have no chance to tell it what scopes to actually use.

To Reproduce
Steps to reproduce the behavior:

1. Use ModelContextProtocol@0.7.0-preview.1
2. Create HttpClientTransportOptions with ClientOAuthOptions and set the Scopes to a subset of the PRM scopes.
3. Connect to the MCP server. It generates an authorisation URL with all scopes defined in PRM.

Expected behavior
If I have specified Scopes in ClientOAuthOptions of HttpClientTransportOptions, the authorize URL should contain the specified scopes.
If I have not specified Scopes in ClientOAuthOptions of HttpClientTransportOptions, the authorize URL should contain the scopes from the PRM.

Additional context
I am quite sure this worked correctly in the past.

[halllo]

Three months ago the, code looked like this, clearly preferencing specified scopes over PRM scopes:

var scopesSupported = protectedResourceMetadata.ScopesSupported;
if (_scopes is not null || scopesSupported.Count > 0)
{
        queryParamsDictionary["scope"] = string.Join(" ", _scopes ?? scopesSupported.ToArray());
}

The behaviour changed with this commit adding support for "incremental scope consent (SEP-835) (#1084)"

[jeffhandley]

The behavior originally flagged (specified Scopes no longer overriding server-advertised scopes) was an intentional move to the spec's strict scope-selection order -- WWW-Authenticate -> PRM scopes_supported -> Scopes fallback -> omit -- introduced with SEP-835 in #1084. Scopes was documented as a fallback, used only when the server doesn't advertise scopes.

But after further discussion here and in #1238, it was concluded there was indeed a need for controlling which scopes are requested even when the server advertises them. Merged PR #1596 added the ScopeSelector delegate: it's invoked with the candidate scopes and its return value replaces them (subset, override, or append). Together with #1479 (auto offline_access, SEP-2207), that covers the scenarios discussed here and in #1238.

Closing as completed. Thanks for all the effort on this, @halllo.