[Feat] Connect OAuth clients to Roomote member tools

[roomote-roomote]

​Opened on behalf of @mrubens. Follow up by mentioning @roomote-roomote, in the web UI, or in Slack.

What changed

• exposed the canonical remote MCP server at the deployment's public /mcp URL and proxied Streamable HTTP requests to the API service
• added OAuth discovery, dynamic public-client registration, S256 PKCE, explicit consent, and resource-bound member access tokens
• added rotating refresh tokens with a fixed 30-day lifetime, hashed Redis storage, atomic rotation, replay revocation, and a standards-compatible revocation endpoint
• isolated each browser authorization in a fresh random refresh-token family while atomically retiring the prior active family for that member and client
• persisted each client's registered grant types so refresh credentials are issued and accepted only for clients that requested them
• explicitly initialized the web auth runtime in the token endpoint so browser authorization can complete token signing in separately bundled route handlers
• exposed signed-in member task capabilities while preserving the narrow legacy compatibility route and its audience boundary
• documented single-domain setup for Claude Code and other OAuth-capable clients using https://<ROOMOTE_DOMAIN>/mcp

Why this change was made

OAuth-capable MCP clients need one stable Roomote URL and credentials that survive short access-token expiry without repeated browser authorization. Live Claude connection testing also exposed that successful consent could still fail at token exchange because the separately bundled token route had not initialized its signing keys.

Impact

Users can connect Claude Code, Claude connectors, Cursor, VS Code, and other compatible clients to https://<ROOMOTE_DOMAIN>/mcp. Browser authorization now completes through token exchange, supported clients remain connected through securely rotated refresh tokens, and replaying a token from an older authorization cannot revoke its replacement session.

[roomote-community]

No new code issues found. See task

• apps/web/src/app/api/mcp-remote-oauth/authorize/route.ts:140-169 now binds approval to a one-time consent token for the signed-in user and exact authorization request.
• apps/web/src/app/api/mcp-remote-oauth/token/route.ts:48-63 now validates the authorization-code binding and PKCE verifier before atomically consuming the code.
• apps/web/src/app/api/mcp-remote-oauth/register/route.ts:14-18 now bounds each registered client's redirect-URI payload, while mcp-remote-oauth.ts caps stored registrations.
• apps/web/src/app/api/mcp-remote-oauth/register/route.ts:43-48 now derives admission from validated metadata rather than caller-controlled forwarding headers; short-lived pending records and active-client quotas prevent permanent pool exhaustion.
• apps/web/src/lib/server/mcp-remote-oauth.ts:32-46 now checks both registration quotas atomically and increments the global bucket only for admitted requests.
• apps/web/src/lib/server/mcp-remote-oauth.ts now creates a random refresh-session family per authorization, preventing an older token replay from revoking a replacement session.

_{Reviewed b2b34b1}

[roomote-roomote]

The refresh-session family isolation finding is fixed in 24d6527.

Each browser authorization now creates a fresh random token family. An atomic per-member/client pointer retires the prior active family, so a replay marker from an older authorization can only affect that old family and cannot revoke its replacement.

Focused tests cover replacement-family isolation, the real Redis lifecycle check passes, and the full pre-push lint, type, and dead-code checks pass. The review thread is resolved and the draft PR metadata reflects the shipped behavior.