Correct the scope-selection migration note and a stale test docstring

The migration entry named the wrong v1 trigger for the removed
authorization-server fallback: it fired when the protected resource
metadata was absent or omitted scopes_supported, not when it published an
empty list. Also note that the offline_access append needs a base scope,
so flows that previously drew only on the authorization server's list
no longer request it.

No-Verification-Needed: doc- and comment-only edits

Author: maxisbey

docs/migration.md

@@ -1995,8 +1995,8 @@ ClientCredentialsOAuthProvider(..., scope="read write")
 
 The client selects the scope to request from the `WWW-Authenticate` challenge, then the protected resource's `scopes_supported`, then the scope the caller configured on the provider (`ClientCredentialsOAuthProvider(scope=...)`, `PrivateKeyJWTOAuthProvider(scope=...)`, or `OAuthClientMetadata(scope=...)`), and otherwise omits it. Two v1 behaviours changed:
 
-* The configured scope is now requested when the server advertises no scopes. v1 silently dropped it and sent the token request scope-less. If a strict authorization server now answers `invalid_scope` for a configured scope it does not allowlist, drop or correct the `scope=` argument.
-* The authorization server's `scopes_supported` no longer supplies the requested scope. v1 fell back to that list, which is the server's whole catalog rather than what the resource needs, so a resource publishing an empty `scopes_supported` could trigger a request for every scope the authorization server supports. If you relied on it, configure the scope on the provider explicitly. The list is still consulted to decide whether `offline_access` may be added ([SEP-2207](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2207)).
+* The configured scope is now requested when the server publishes no scopes (its `scopes_supported` absent or empty). v1 silently dropped it and sent the token request scope-less. If a strict authorization server now answers `invalid_scope` for a configured scope it does not allowlist, drop or correct the `scope=` argument.
+* The authorization server's `scopes_supported` no longer supplies the requested scope. When the protected resource metadata was absent or omitted `scopes_supported`, v1 requested that entire list — the server's whole catalog rather than what the resource needs. If you relied on it, configure the scope on the provider explicitly. The list is still consulted to decide whether `offline_access` may be added ([SEP-2207](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2207)), but that append needs a base scope: a flow whose only scope source was the authorization server's list now also sends no `offline_access` and so receives no refresh token — configure the scope on the provider to keep requesting one.
 
 ### Client rejects authorization server metadata with a mismatched `issuer`
 

tests/interaction/auth/test_lifecycle.py

@@ -404,10 +404,10 @@ async def test_client_credentials_provider_obtains_a_token_without_an_authorize_
 async def test_client_credentials_provider_requests_its_configured_scope_when_the_server_advertises_none() -> None:
     """With no scopes advertised, the provider's configured `scope` reaches the `/token` body.
 
-    Both metadata documents omit `scopes_supported` (absent, not empty - an empty list would
-    itself mean "request none"), so the spec's WWW-Authenticate/PRM chain yields nothing and
-    the SDK falls back to the scope the caller configured on the provider — an SDK-defined tier
-    below the spec's chain (see the divergence on the requirement).
+    Both metadata documents publish no scopes (an empty list would fall through the same way),
+    so the spec's WWW-Authenticate/PRM chain yields nothing and the SDK falls back to the scope
+    the caller configured on the provider — an SDK-defined tier below the spec's chain (see
+    the divergence on the requirement).
     """
     recorded, on_request = record_requests()
     provider = InMemoryAuthorizationServerProvider()