GeezerVison

Closes CODAGT-1422

After upgrading to v2.38, Coder Agents can't connect to Coder's own MCP server if its MCP server config was created before the upgrade. When an admin creates an OAuth2 MCP server config without any scopes, we save the authorization server's entire scopes_supported list and send it on every connect. Before v2.38 that list included the task:* scopes, which #28750 removed. Since #28178, /oauth2/authorize rejects the whole request if it names a scope outside the catalog, so connecting fails with:

'task:*': unknown or unsupported scope

The issue suggests a migration that strips task:* from mcp_server_configs, but I don't think that's the right fix. We can't backport it to 2.38, as main already has migrations past the last one on release/2.38. A config with only task:* scopes would be left with none, and requesting no scope gets you coder:all. The column also holds scopes for third-party MCP servers. Any other OAuth2 client that cached the old scopes_supported would also stay broken, as would every client the next time we remove a scope.

To fix, we'll retire removed scopes rather than delete them. There's now a small list of retired scope names next to the scope catalog, and the authorization server drops those names from a request and grants the rest. RFC 6749 §3.3 lets the server ignore part of the requested scope, and the token response already returns the scope that was issued. Names that were never in the catalog are still rejected, and so is a request of only retired names, so it can't widen into a broader default grant (e.g. coder:all). Existing configs then connect without anyone editing them.

If we'd assumed from the start that scopes get removed, we'd have retired them rather than deleted them, and that's all this does. It fixes the cause rather than the one MCP config symptom, it's code only so it cherry-picks cleanly onto release/2.38, and the next removed scope just moves into the retired list.

Third-party MCP servers that remove a scope will still break Agents the same way, since our MCP client saves the authorization server's scopes_supported instead of following the MCP spec's scope selection. I've left that for a follow-up.