Gateway front: restore cut-off paths and confirm hosting facts for the privacy policy

Observed 2026-09-01: mcp.internetcomputer.org is now fronted by Internet Computer HTTP-gateway infrastructure — DNS resolves to addresses registered to DFINITY Stiftung, and the origin serves the gateway fleet's shared certificate (SANs *.internetcomputer.org, *.ic0.app, *.icp0.io, icp-api.io, …). The front terminates TLS, forwards /mcp*, /.well-known/oauth-* and /.well-known/ii-auth-callbacks to the application, and answers every other path with a 308 to https://internetcomputer.org/icp-mcp/.

The connect flow still works end to end (the callbacks document and the pinned callback page under /mcp/oauth/ pass through). Cut off at the edge today:

• /.well-known/ii-app-metadata — served at the origin root since #169 for Internet Identity's consent screen; II's fetch now gets a redirect to an HTML page instead.
• /version — the build probe the submission checklists, the status dashboard, and .github/workflows/health.yml read. The scheduled health run presumably fails since the move.
• /status/ — the status dashboard the Anthropic listing cites for health visibility.
• /.well-known/openai-apps-challenge — the OpenAI domain-verification endpoint; the portal's exact-match check cannot reach the app through a redirect (docs/openai-directory-submission.md, blocker 1).
• /robots.txt and /favicon.svg (the connect and error screens link the favicon).

Asks, in order:

1. Forward the paths above at the fronting layer (allowlist entries alongside the three already forwarded) — or decide per path that the redirect is intended, and update the docs and workflows that cite it.
2. Confirm the hosting facts the privacy policy needs before its next republication (the policy draft's header note lists them): whether the application host is still the deployment deploy/native describes (Amazon Web Services, Frankfurt), who operates the fronting layer and where it terminates TLS, and what that layer logs — especially client addresses and request URLs, and for how long. Sections 2 ("Our hosting provider"), 3 (International Transfers) and 5 (What Our Logs Contain) hang on those answers. This continues the deployment-audit intent of #122 on the deployment's current edge; the application-host items of that audit (journald contents, coredump state, AWS-side logs, support-access posture) still need on-host access and belong here too if that host remains in the path.
3. Re-verify the submission-guide checklists (docs/anthropic-directory-submission.md, docs/openai-directory-submission.md) once 1–2 are decided, and re-run a /version check that production carries the intended release.

Inspect the fronting-layer allowlist and .github/workflows/health.yml, then verify the listed endpoints and their expected responses. Read docs/anthropic-directory-submission.md, docs/openai-directory-submission.md, and the privacy policy draft's header note to identify claims requiring confirmation. Done means the paths and workflows work or are intentionally documented, hosting and logging facts are confirmed, and the submission checks are re-run.