feat(mcp): add an OAuth 2.1 authorization-server bridge for remote connectors

Let a remote MCP client (Claude.ai, ChatGPT) self-register and connect to
the `/mcp` endpoint over OAuth 2.1 + PKCE, bridged onto the existing `hlk_`
Bearer model — no parallel identity store.

- Discovery: RFC 9728 Protected Resource Metadata and RFC 8414 Authorization
  Server Metadata at `/.well-known/oauth-protected-resource` and
  `/.well-known/oauth-authorization-server` (added to the proxy allowlist).
- `/api/mcp/oauth/authorize` — consent gate backed by the existing session;
  a code is only issued on an authenticated POST decision, never on a GET.
- `/api/mcp/oauth/token` — authorization-code and refresh-token grants with
  mandatory PKCE S256, single-use codes, and rotating refresh tokens. The
  access token is an ordinary short-lived `hlk_` token scoped `health:read`.
- `/api/mcp/oauth/register` — RFC 7591 DCR fallback; CIMD (SEP-991) is the
  preferred path and resolves client metadata through `safeFetch`.
- Audience binding (RFC 8707): every token is bound to the canonical `/mcp`
  resource URI; a mismatched `resource` is rejected at authorize and token.
- The grant artifacts (code, refresh, DCR client id) are HMAC-signed,
  self-describing, and domain-separated; the central log redactors scrub
  them plus the PKCE verifier.

src/proxy.ts

@@ -71,6 +71,13 @@ const PUBLIC_PATHS = [
  */
 const WELL_KNOWN_PUBLIC_PATHS = new Set<string>([
   "/.well-known/apple-app-site-association",
+  // v1.22.0 — OAuth discovery for the remote MCP connector. A remote client
+  // (Claude.ai / ChatGPT) reads these unauthenticated to bootstrap the OAuth
+  // 2.1 + PKCE flow from the pasted `/mcp` URL alone: RFC 9728 Protected
+  // Resource Metadata + RFC 8414 Authorization Server Metadata. Both are
+  // public, deterministic, secret-free discovery documents.
+  "/.well-known/oauth-protected-resource",
+  "/.well-known/oauth-authorization-server",
 ]);
 
 /**