feat: accumulate client-side scopes during step-up authorization (SEP-2350)

[stefanoamorelli]

Closes #877

Motivation and Context

SEP-2350 makes scope accumulation a client responsibility. A 403 / insufficient_scope challenge carries only the scopes for the current operation (RFC 6750 §3.1), so on re-authorization the client must request the union of what it asked for before and what was just challenged.

select_base_scopes() returned a single source, so a challenge replaced the earlier scopes instead of widening them, and step-up dropped previously granted permissions (the auth/scope-step-up conformance test failed for this). This PR unions current_scopes, the WWW-Authenticate challenge, and the resource metadata scopes (RFC 9728); defaults only seed the first request. On exchange, an explicit scope list stays authoritative so a server can still narrow the grant, but when the server omits scope (RFC 6749 §5.1) the accumulated set is retained rather than cleared.

How Has This Been Tested?

Added unit tests for multi-round accumulation, union-not-replace, dedup of an already-requested challenge, and resource metadata accumulation. The rmcp suite passes with the auth feature, and cargo +nightly fmt --all and clippy are clean.

Breaking Changes

No API changes. The behavior change is required by the SEP: re-authorization requests the union of prior and challenged scopes. exchange_code_for_token still honors an explicit downgrade from the server and only retains the accumulated set when the server omits scope, so a previously granted scope is not reported back unless the server kept granting it.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

This is the client half of SEP-2350; server-side per-operation scope reporting is out of scope for the SDK. No new error handling was needed since the change only widens the requested set.

[michaelneale]

nice @stefanoamorelli - only thought so far current_scopes is remembered, but if scope is omitted when a token response is returned when user asked for an additional scope, it won't remember what it asked for (ie will only fall back to current_scopes, not the new ones). Not sure if that is intentional or not. I am a little confused as to what is meant to happen when a token comes back without a scopes list.

Looks like that should be fixed:

scope
         OPTIONAL, if identical to the scope requested by the client;
         otherwise, REQUIRED.  The scope of the access token as
         described by [Section 3.3](https://www.rfc-editor.org/info/rfc6749/#section-3.3).

https://www.rfc-editor.org/info/rfc6749/#section-5.1

so I think that is all, if that can be patched then this could be good to go.

[michaelneale]

Around the exchange_code_for_token change, roughly original/current PR hunk near line 1239:

let granted_scopes: Vec<String> = match token_result.scopes() {
    Some(scopes) => scopes.iter().map(|s| s.to_string()).collect(),
    None => self.current_scopes.read().await.clone(),
};

as mentioned in other comment, I think that should be the scopes requested, not the current scopes?