DCR for the Cloudflare portal: persist dynamic registrations and allowlist the portal callbacks

Blocks switching the api upstream of the Cloudflare MCP portal to automatic (DCR) mode: mctlhq/mctl-gitops#1363, under the org rule mctlhq/.github#137.

What was checked (2026-09-24)

Restriction: good. POST https://api.mctl.ai/oauth/register with redirect_uris: ["https://evil.example/cb"] gets 400 invalid_redirect_uri ("redirect_uri "https://evil.example/cb\" is not allowed").
Blocker 1, the registry is in-memory. internal/auth/oauth_server.go (around line 431) says: "the registry below is in-memory, so a restart drops the registration while the client keeps its cached client_id". In automatic mode the portal registers once and caches the client_id. Every mctl-api rollout would then leave the portal with an unknown client (invalid_client), and the api upstream would stop working until someone re-authenticates it in the dashboard.
Blocker 2, callbacks not allowlisted. OAUTH_ALLOWED_REDIRECT_URIS is not set in services/admins/mctl-api/values.yaml, so the defaults apply (glama, smithery, chatgpt). The portal's DCR registration carries both:
- https://mcp.mctl.ai/servers-callback (user sign-in);
- https://dash.cloudflare.com/6a09f637d20e1f66a8e9d45ebe778058/one/access-controls/ai-controls/mcp-server/oauth-callback/api (admin "Authenticate server"; measured on coolify, see portal: seerrsense, api and coolify-mcp under mcp-servers.tf in automatic (DCR) mode mctl-gitops#1363).

Persist dynamically registered clients, for example alongside the existing RefreshStore, so a registration survives restarts. Consider idempotency per redirect set, as in seerrsense#75, to bound the rows.
Allowlist the two portal callbacks above. Use exact entries, not a dash.cloudflare.com/* prefix.
A DCR client that names no scope gets mctl, the only scope.

After a mctl-api rollout, a DCR client registered before it still resolves. Then the api portal upstream can be switched to automatic in #1363.

🤖 Generated with Claude Code