During a rollout an app's host briefly serves forge pages (title forge, forge 404s) beside the app; app hosts must never fall through to the forge router #6726

Seen 2026-10-27 about 02:57–03:00Z, during the 0.7.274 rollout (the steward's read-only audit of arm--forge-trevato-apps.open-platform.sh). For a few minutes the app's host answered with the forge's own pages: / and /signin 200 with <title>forge</title>; /status, /admin, /version and /__forge/signin "Not found · forge". These carried forge headers (link: </llms.txt>, server-timing: app;dur…), not the app's. Meanwhile other paths on the same host (/story, /link, /_plat/*) were answered by the app. Both answered the same host at once. The owner saw a "forge interface" on the workshop and was confused. By 03:00:52Z everything was the app again.

src/apps/proxy.ts:121-127 says an unresolved app host answers "unknown", never forge pages. During a rollout that didn't hold.

Done when:

1. An app host never renders forge pages. While the new forge pod has not yet loaded its app table (or during handover), app-host requests wait briefly (≤ 2 s) or get a small "the app is coming back" holding page with Retry-After. They are never routed to the forge's own router.
2. The front-door check adds a probe that GET / on an app host never has <title>forge</title>.
3. Test: boot the server with apps not yet loaded; a request for an app host returns the holding page (503 + Retry-After), not a forge page, and the app's page once loaded.

Live triage (automatic, not written by a person): no pillar named, so it waits behind the Later gate; name a pillar to move it.