Add scopes_supported to Protected Resource Metadata

What does this MR do and why?

Adds scopes_supported field to the OAuth Protected Resource Metadata endpoint (/.well-known/oauth-protected-resource) per RFC 9728.

This tells MCP clients (like mcp-remote used by Cursor, Claude Desktop, etc.) that the MCP resource only supports the mcp scope, preventing them from requesting all available OAuth scopes from the Authorization Server Metadata.

Background

After mcp-remote PR #193 (released as v0.1.32), MCP clients now implement RFC 9728 Protected Resource Metadata discovery with the following scope priority:

1. User-provided scope from static OAuth client metadata (highest)
2. Scope from WWW-Authenticate header
3. scopes_supported from Protected Resource Metadata ← this MR
4. Scope from client registration response
5. scopes_supported from Authorization Server Metadata
6. Fallback default (openid email profile)

Without scopes_supported in our Protected Resource Metadata, clients fall back to priority 5 (Authorization Server Metadata), which exposes ALL available GitLab OAuth scopes. This causes clients like Cursor to request all scopes instead of just mcp.

References

• #585699 (closed) - MCP Server OAuth flow fails for all scope requests on GitLab.com
• !219070 (merged) - Forces MCP scope for dynamic applications (defensive fix)
• This MR provides the proper RFC 9728 compliant solution

How to set up and validate locally

curl -s http://gdk.test:3000/.well-known/oauth-protected-resource | jq

Should return:

{
  "resource": ["http://gdk.test:3000"],
  "authorization_servers": ["http://gdk.test:3000"],
  "scopes_supported": ["mcp"]
}

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.