fix(mcp): RFC 9728 protected-resource metadata path + audience binding

Codex/RFC review showed that Claude Desktop addresses the MCP resource
as <PUBLIC_URL>/mcp (the streamable-HTTP endpoint) rather than the
base URL. Per RFC 9728 the protected-resource metadata then lives at
.well-known/oauth-protected-resource inserted between host and path:

  https://mcp.buildmymcpserver.com/.well-known/oauth-protected-resource/<slug>/mcp

Runner template now:
  - publishes `resource: <PUBLIC_URL>/mcp`
  - sets WWW-Authenticate to the RFC 9728 well-known URL
  - serves /.well-known/oauth-protected-resource[/*] so the metadata
    answers at both the legacy and RFC paths during transition
  - accepts both audiences (<PUBLIC_URL>/mcp + <PUBLIC_URL>) during
    rollout so already-issued tokens keep working

API:
  - resolveServerByResource() tries port first, then path segment
    (production path-routing), with a guard against treating "mcp" as
    a tenant slug
  - AS metadata advertises resource_parameter_supported: true

nginx (scripts/setup-runner-tls.sh + scripts/bmm-mcp-runners.nginx):
  - new location matches /.well-known/oauth-protected-resource/<slug>/...
    and proxies to the slug's runner with the slug stripped, so the
    runner sees the local well-known path

Docs (oauth + api-reference) updated to the RFC paths.

apps/web/app/docs/api-reference/page.tsx

@@ -60,7 +60,7 @@ export default function ApiReference() {
 
       <DocsH2 id="oauth">OAuth (clients of generated servers, not dashboard)</DocsH2>
       <DocsP>
-        <Mono>GET /oauth/.well-known/oauth-authorization-server</Mono> — RFC 8414 metadata.
+        <Mono>GET /.well-known/oauth-authorization-server/oauth</Mono> — RFC 8414 metadata.
       </DocsP>
       <DocsP><Mono>GET /oauth/jwks</Mono> — RS256 public key for verifying access tokens.</DocsP>
       <DocsP><Mono>POST /oauth/register</Mono> — RFC 7591 dynamic client registration.</DocsP>