The forge's app proxy adds under 5 ms to a warm app's answer, measured on loopback and named in the gate #8186

Intent: an app on the forge feels as fast as the forge. From one client, production's lab app reports app;dur=1–4 ms in Server-Timing yet takes 2–8 s end to end for / and /explore, while the forge's own /robots.txt (0.4 ms) takes 0.7–2.8 s from the same client: the proxied hop costs seconds more than the forge's own.

Done:

• [ ] A test boots a forge with a warm app on loopback (the scaffold app), requests / through the proxy 50 times, and asserts the proxy's median overhead over a direct fetch of the app's port is under 5 ms and its p95 under 20 ms, with and without the toolbar rewrite; the test prints the five slowest phases on failure.
• [ ] Whatever the test finds over budget is fixed in src/apps/proxy.ts (per-request lookups such as admit, envStatus, door pulls or crewNow cached or moved off the hot path), not waited out.
• [ ] The pull says, with numbers from production before and after, whether the remaining seconds are in the forge or in front of it, so the next issue can name the hop.

Files: src/apps/proxy.ts, src/apps/toolbar.ts, test/apps-proxy-timing.test.ts (new) Risks: timing tests flake under load; compare to a direct fetch in the same test, not to a wall-clock constant alone, and keep it under 1 s. Do not touch src/http/server.ts (hot). #8155 (in flight) adds the forge's time to Server-Timing; this one does not need it. Fits: @scout.