fix(agent-readiness): host-aware oauth-protected-resource endpoint (#3351)

* fix(agent-readiness): host-aware oauth-protected-resource endpoint

isitagentready.com enforces that `authorization_servers[*]` share
origin with `resource` (same-origin rule, matches Cloudflare's
mcp.cloudflare.com reference — RFC 9728 §3 permits split origins
but the scanner is stricter).

A single static file served from 3 hosts (apex/www/api) can only
satisfy one origin at a time. Replacing with an edge function that
derives both `resource` and `authorization_servers` from the
request `Host` header gives each origin self-consistent metadata.

No server-side behavior changes: api/oauth/*.js token issuer
doesn't bind tokens to a specific resource value (verified in
the previous PR's review).

* fix(agent-readiness): host-derive resource_metadata + runtime guardrails

Addresses P1/P2 review on this PR:

- api/mcp.ts (P1): WWW-Authenticate resource_metadata was still
  hardcoded to apex even when the client hit api.worldmonitor.app.
  Derive from request.headers.get('host') so each client gets a
  pointer matching their own origin — consistent with the host-
  aware edge function this PR introduces.
- api/oauth-protected-resource.ts (P2): add Vary: Host so any
  intermediate cache keys by hostname (belt + suspenders on top of
  Vercel's routing).
- tests/deploy-config.test.mjs (P2): replace regex-on-source with
  a runtime handler invocation asserting origin-matching metadata
  for apex/www/api hosts, and tighten the api/mcp.ts assertion to
  require host-derived resource_metadata construction.

---------

Co-authored-by: Elie Habib <elie@worldmonitor.app>

api/oauth-protected-resource.ts

@@ -0,0 +1,46 @@
+/**
+ * GET /.well-known/oauth-protected-resource (rewritten to /api/oauth-protected-resource)
+ *
+ * RFC 9728 OAuth Protected Resource Metadata, served dynamically so every
+ * host that terminates the request (apex worldmonitor.app, www, or
+ * api.worldmonitor.app) returns self-consistent `resource` +
+ * `authorization_servers` pointing at itself.
+ *
+ * Why dynamic: scanners like isitagentready.com (and Cloudflare's reference
+ * at mcp.cloudflare.com) enforce that `authorization_servers[*]` share
+ * origin with `resource`. A single static file served from 3 hosts can only
+ * satisfy one origin at a time; deriving both fields from the request Host
+ * header makes the response correct regardless of which host is scanned.
+ *
+ * RFC 9728 §3 permits split origins, but the scanner is stricter — and
+ * same-origin by construction is simpler than arguing with scanner authors.
+ */
+
+export const config = { runtime: 'edge' };
+
+export default function handler(req: Request): Response {
+  const url = new URL(req.url);
+  const host = req.headers.get('host') ?? url.host;
+  const origin = `https://${host}`;
+
+  const body = JSON.stringify({
+    resource: origin,
+    authorization_servers: [origin],
+    bearer_methods_supported: ['header'],
+    scopes_supported: ['mcp'],
+  });
+
+  return new Response(body, {
+    status: 200,
+    headers: {
+      'Content-Type': 'application/json',
+      'Cache-Control': 'public, max-age=3600',
+      'Access-Control-Allow-Origin': '*',
+      // Response body varies by Host (resource/authorization_servers derived
+      // from it). Any intermediate cache keying on path alone could serve
+      // wrong-origin metadata across hosts. Vercel's own router is per-host,
+      // but this is belt-and-braces against downstream caches.
+      'Vary': 'Host',
+    },
+  });
+}