### Check for existing issues

- [x] I have searched the existing issues and checked that my issue is not a duplicate.

### The Feature

## Problem

When the LiteLLM MCP Gateway is protected by JWT auth (`enable_jwt_auth`), it acts as a *bring-your-own-token* resource server: a request without a valid token just gets a bare `401`. A generic MCP client (Claude Code, VS Code, Cursor…) has no way to know **which authorization server to use** or how to start an OAuth flow, so the login screen never triggers automatically.

The MCP authorization spec (OAuth 2.1 + **RFC 9728 Protected Resource Metadata**) solves this: the resource server must advertise its trusted authorization server(s) so clients can auto-discover, register (DCR), and obtain a token without manual configuration (get an api key).

Today LiteLLM only implements this discovery for the **outbound** direction (LiteLLM → upstream MCP servers), not for **inbound** auth (MCP client → LiteLLM).

## Proposed solution

For the inbound MCP endpoint, when a request is unauthenticated:

1. Serve `GET /.well-known/oauth-protected-resource` (RFC 9728) returning the configured `authorization_servers` (e.g. our external IdP) and `res…