feat(mcp): Dodo-owned DCR OAuth flow + start/complete tools

[jonnyparris]

What

Dodo runs its own DCR registration + token exchange against an upstream OAuth provider. A local helper handles only the browser-side authorize step on a loopback callback. Dodo gets a refresh chain that doesn't share fate with any local OAuth client (OpenCode, Cursor, Claude Desktop, etc).

Why

PR #90 added a piggyback path where the user pushes OpenCode's existing tokens into Dodo. That works but refresh tokens rotate — the first time Dodo refreshes, OpenCode's local copy becomes invalid, forcing the user to re-auth locally.

This PR fixes that. Each tool has its own client_id + refresh chain. They never interfere.

How

Two new MCP tools form a two-step dance:

1. start_dcr_oauth_flow({mcpUrl, mcpName})
   → Dodo:
     - discovers OAuth endpoints from /.well-known docs
     - POSTs DCR with redirect_uris=["http://127.0.0.1:PORT/callback"]
     - generates PKCE code_verifier + code_challenge (S256)
     - generates state nonce (32 random bytes hex)
     - persists {client_id, code_verifier, redirect_uri, token_endpoint, ...}
       in encrypted_secrets keyed by state (10-min TTL)
   → returns { state, authUrl, redirectUri }

2. (local helper opens authUrl in browser, binds 127.0.0.1:PORT/callback,
   catches the redirect with ?code= and ?state=)

3. complete_dcr_oauth_flow({state, code})
   → Dodo:
     - loads pending dance by state, validates TTL
     - POSTs to token_endpoint with grant_type=authorization_code,
       code, code_verifier, redirect_uri (loopback), client_id
     - stores resulting tokens via the existing upsertRefreshTokenMcp
       path → mcp_configs row with auth_type='refresh_token'
     - deletes pending state
   → returns { id, name, url } of the new integration

Why this is safe to run from a hosted Worker

• DCR is unauthenticated — anyone can register a client. cf-portal accepts loopback redirect URIs in DCR.
• PKCE binds authorize to token exchange. code_verifier never leaves Dodo's storage; a captured code is useless without it.
• State nonce is 32 random bytes hex; the helper must return the matching state alongside the code.
• redirect_uri in token exchange matches the one sent in authorize (loopback). cf-portal's authorize endpoint accepts loopback; the token endpoint just checks the redirect_uri matches the registered one (it doesn't enforce loopback).

Storage

• Pending dances: encrypted_secrets["oauth_dcr_pending:<state>"] — JSON blob, 10-min TTL.
• Completed tokens: existing mcp_configs row with auth_type='refresh_token' + encrypted_secrets["mcp:<id>:{access_token,refresh_token,expires_at}"]. Reuses everything from PR feat(mcp): refresh-token auth type + set_refresh_token_mcp tool #90.

Tests

Six new in test/oauth-dcr-flow-unit.test.ts:

• Discovery from well-known docs, DCR call, authorize URL construction (PKCE + state present, correct shape)
• Explicit endpoint overrides bypass discovery
• 502 surfaced when DCR fails
• Token exchange + persist via refresh-token path; verifies request body shape (grant_type, code, code_verifier, redirect_uri, client_id)
• Unknown state rejected
• Token endpoint error surfaced

829/829 pass (823 + 6 new). Typecheck clean.

Also fixes a TypeScript narrowing quirk in the existing PR #90 test — let captured = null inside a closure narrowed to never after stricter type checking. Switched to a {value: T | null} holder.

Follow-up (separate PR)

A small bash helper + slash command in agent-hq that orchestrates the local side:

1. Calls start_dcr_oauth_flow via Dodo's MCP
2. Spins up a Python http.server on 127.0.0.1:19876
3. Opens the authorize URL in the browser
4. Catches the callback, extracts code + state
5. Calls complete_dcr_oauth_flow
6. Reports the result

Not in this PR because Dodo doesn't ship the helper — it lives in agent-hq.

beep-boop-🤖