feat!: org-scope MCP server configs with RBAC - #27942

Moves mcp_server_configs from deployment scope to organization scope so each organization fully controls the MCP servers its members can use with Coder Agents.

Summary

• Migration: adds organization_id (NOT NULL, FK) and keeps existing rows as the default organization's originals with credentials intact. Other organizations start with no MCP servers and configure their own; nothing is copied across organizations. Chats outside the default organization keep any now-cross-organization mcp_server_ids entries; the runtime already ignores IDs that do not resolve in the chat's organization, so no data rewrite is needed. Slug uniqueness becomes (organization_id, slug).

• RBAC: new org-scoped ResourceMCPServerConfig with regosql converter and GetAuthorizedMCPServerConfigs; org admins get in-org CRUD, org members get read (replaced by ACL evaluation in the follow-up ACL PR in this stack).

• API: all config routes nest under the organization, matching templates: POST|GET /api/experimental/organizations/{organization}/mcp-servers and GET|PATCH|DELETE .../mcp-servers/{mcpserverconfig} (plus oauth2/connect), resolved by a read-only param middleware that conceals read-denied and cross-organization access as 404. Two routes stay on the frozen /api/experimental/mcp/servers/{mcpServer} block: the OAuth2 callback (the redirect URI baked into existing AS-side client registrations) and oauth2/disconnect, which must remain reachable by users removed from the organization so they can still revoke their token grant.

• Chat runtime: selection validation and generation resolve configs strictly by IDs, enabled state, and the chat's organization in SQL; requested duplicates are normalized; invalid or cross-org IDs are rejected with the precise ID list. IDs already persisted on a chat are exempt from message-time rejection so disabling a selected server never blocks sends; generation skips servers that are no longer usable.

• Frontend: API layer and admin settings pages target the new endpoints. The admin page manages the default organization's servers; the org picker is tracked separately (CODAGT-714).

• Security hardening from review: OAuth user grants are additionally bound to oauth2_revocation_url (changing it invalidates grants, and a racing OAuth callback gets 409 instead of recreating a grant). Stack-wide SSRF protection for MCP config-directed traffic was split into its own PR at the top of this stack (feat: enforce SSRF protection for MCP config-directed traffic #28242) to keep this diff reviewable; this PR keeps main's existing discovery IP-range guard. OAuth2 auto-discovery now completes before the config row is inserted: a failed discovery persists nothing, and there is no provisional row that concurrent updates could race against.

Two follow-up PRs in this stack were split out to keep this diff reviewable: #28064 completes the swagger annotations for the moved routes (main already ships these experimental MCP handlers unannotated), and #28065 carries hardening fixes and regression pins on top of the cutover.

• Force On enforcement (landed on main mid-review) is org-scoped: the forced set is read per chat organization (GetForcedMCPServerConfigsByOrganization), so another organization's force_on server never attaches to a chat.

Breaking changes (experimental API)

The MCP server config endpoints move from the deployment-scoped /api/experimental/mcp/servers block to organization-nested paths: POST|GET /api/experimental/organizations/{organization}/mcp-servers and GET|PATCH|DELETE /api/experimental/organizations/{organization}/mcp-servers/{mcpserverconfig} (plus oauth2/connect). The old paths are removed, so API consumers must supply an organization. Two routes intentionally stay on the frozen /api/experimental/mcp/servers/{mcpServer} block: the OAuth2 callback (its redirect URI is baked into existing AS-side client registrations) and oauth2/disconnect (must remain reachable by users removed from the organization). These endpoints are under /api/experimental, so no deprecation window is provided.

Rolling upgrades

During a rolling deploy, an old replica creating an MCP config can fail the new NOT NULL organization_id constraint until it is upgraded (reads are unaffected: old binaries' generated queries select their own column lists). This matches the repo's existing precedent for additive NOT NULL migrations (000562) and affects only the admin config-create path in the upgrade window.

Upgrades are expected to run in scheduled maintenance downtime with the database locked during migration, so the migration ships no rolling-upgrade compatibility machinery. The down migration deletes organization-created configs (their chat references are cleaned by the 000510 delete trigger) and restores deployment-wide slug uniqueness.

Part of the MCP org-separation stack (CODAGT-711 -> CODAGT-717 audit -> CODAGT-712 ACLs -> CODAGT-806 token RBAC).

Closes https://linear.app/codercom/issue/CODAGT-711

UAT: validated end to end on a two-org dogfood deployment, including a real pre-migration to post-migration upgrade, cross-org isolation (404s), same-slug-two-orgs, chat selection gating, and a live MCP tool call through the org-scoped generation path. The migration was later revised to keep existing rows in the default organization only (no per-organization copies); that revision is covered by the migration test suite.

Mux (AI agent) authored this PR on Mike's behalf.