The MCP_APPROVED_CLIENTS and MCP_DENIED_CLIENTS cookies grow without bound as users approve/deny dynamically registered clients. In deployments behind reverse proxies with header size limits (Cloudflare, Nginx), this eventually causes OAuth consent requests to fail with 502s.

The fix treats the cookie as an LRU list capped at 25 entries. When a new client is approved or denied, it's moved to the end of the list and the oldest entries are evicted if the cap is exceeded. This keeps the Cookie header bounded while preserving the "don't ask me again" UX for recently used clients. Evicted clients simply see the consent page again on their next OAuth flow.

We considered moving consent memory to server-side storage, but these cookies exist specifically so that consent decisions survive without depending on server state. A server-side approach requires a browser session identifier cookie to correlate the browser with stored decisions. If that identifier is a session cookie, consent memory is lost when the browser closes, defeating the purpose. If it's a persistent cookie, you need the server-side store to also be persistent (Redis, Postgres), or consent is lost on server restart. Most deployments use in-memory stores, where all other OAuth state (client registrations, tokens) is already ephemeral, so tying consent to server-side storage would make it less reliable than the cookie approach for the common case. The LRU cap solves the production issue directly without adding infrastructure requirements.

Closes #3747