Describe the bug

When we have a scenario like this:

• supported_scopes: [read, write, admin]
• implicit required default scope read that the client doesn't know about unless they read the server's docs
• user attempts auth with scope omitted, gets invalid_scope error
• user attempts auth again with read write admin as scope parameter... and gets way more privilege than it needs. (problem is the client doesn't know what to pick here.)

The difficulty is that there isn't an information channel in the resource metadata to indicate a required default scope, only "all available scopes". So what we want to do is this:

1. If a scope was scope included from a 401 WWW-Authenticate header response, use that as the scope parameter
2. Omit scope otherwise, and let the server give defaults
3. If after omitting scope, we get an invalid_scope error, include all of supported_scopes as a final fallback.

We also want to encourage servers to provide default scopes if the scope parameter is omitted, but this issue is specifically focusing on the client.

We'll also want to update the example auth server to be able to demonstrate this behavior.

Note: we'll need the changes in this PR in order to properly respond to a invalid_scope error.

To Reproduce
This issue comes up in clients talking to servers that have required default scopes as we currently leave the scope parameter blank.

Expected behavior
Client's have a way to provide a default scope if the server requires it, without requesting ALL scopes all the time.

Logs

Additional context

See also:
#564
modelcontextprotocol/inspector#455