Redirect authorization-server-metadata probes to the real AS (AuthKit).

Correct MCP clients read authorization_servers from the protected-resource metadata (above) and fetch AS metadata FROM the AS. But several deployed clients — and the MCP 2025-03-26 auth flow, which assumes the MCP server is its own authorization server — instead probe RFC 8414 metadata on the RESOURCE origin. Without a handler here they 404 and dead-end at the /mcp 401. Observed live 2026-07-02: external clients (and Jay's own connector test) hit all four AS/OIDC well-known paths on this origin, every one 404, then bounced back to 401 — the "MCP not working for users" report. A 302 to AuthKit's own well-known keeps the returned metadata issuer matching the final fetch origin (RFC 8414 §3.3), so strict clients accept it and inbound token validation is unchanged. The X-API-Key path is untouched. 404 when OAuth is disabled (there is no AS to point at).