fix(auth): align OAuth metadata discovery ordering

[jstar0]

Fixes #878.

Summary

• align path-bearing authorization-server discovery with the MCP authorization spec / RFC 8414 ordering
• keep OAuth authorization-server metadata discovery ahead of OpenID Connect fallback candidates
• add regression coverage for both candidate ordering and a real client credentials discovery flow

Changes

For a resource URL such as https://example.com/mcp, the direct authorization-server discovery list is:

• https://example.com/.well-known/oauth-authorization-server/mcp
• https://example.com/.well-known/openid-configuration/mcp
• https://example.com/mcp/.well-known/openid-configuration
• https://example.com/.well-known/oauth-authorization-server

The first three entries match the path-bearing issuer ordering from the MCP authorization spec. The existing canonical OAuth fallback remains last.

The client credentials regression now serves metadata at the RFC 8414 path-inserted OAuth endpoint, so the test exercises the same URL form as the candidate builder.

Verification

cargo test -p rmcp --features auth generate_discovery_urls
cargo test -p rmcp --features auth --test test_client_credentials test_client_credentials_discovers_path_inserted_oauth_metadata
cargo test -p rmcp --features auth
cargo test --all-features
cargo fmt --all -- --check
cargo clippy -p rmcp --features auth --lib -- -D warnings
cargo clippy -p rmcp --features auth --test test_client_credentials -- -D warnings

[michaelneale]

thanks @jstar0 from a brief reading of the spec: https://www.rfc-editor.org/info/rfc8414/#section-3.1 - then the tenant should be at the end, not before .well-known:

ie:

https://auth.example.com/.well-known/oauth-authorization-server/tenant1

not so much:

https://auth.example.com/tenant1/.well-known/oauth-authorization-server

I think, but otherwise looking good.