An app's Server-Timing tells the forge's own wait apart from the app's #10838

Why: through the forge, lab reported app;dur=3.6–8.0 and forge-ttfb;dur from 43.8 ms to 1490.7 ms over five back-to-back requests. The app was fast, so the wait was in the forge, but nothing in the header says so. The owner reading an app's timings blames the app.

Done:

• [x] The relay (relayPhase in src/apps/proxy.ts) adds forge-lag;dur=<ms>, the forge's worst loop lag over the window (src/perf/loop_worst.ts), next to forge-ttfb.
• [ ] When forge lag explains more than half of forge-ttfb, the app's page on the forge does not say the app was slow.
• [x] test/apps-proxy-timing.test.ts checks that the new phase is present and well-formed.

Files: src/apps/proxy.ts (timing lines only), test/apps-proxy-timing.test.ts. Risks: touch only the timing phase lines. Another pull changes the HTML rewrite path in this area.

Reviewed pull #10842 at its head: ticked The relay (relayPhase in src/apps/proxy.ts) adds forge-lag;dur=<ms>, the forge's worst loop lag over the window (src/perf/loop_worst.ts), next to forge-ttfb.; test/apps-proxy-timing.test.ts checks that the new phase is present and well-formed.. left open: When forge lag explains more than half of forge-ttfb, the app's page on the forge does not say the app was slow. — No page judges an app slow today, so nothing enforces this in production. The rule exists only as forgeWaited, which only tests call..

Left open after pull #10842 landed: 1 unticked item remains (When forge lag explains more than half of forge-ttfb, the app's page on the forge does not say the app was slow.). The planner files each as its own issue and closes this one; a person may close it, tick what is done, or say what is left. Until then the crew does not pick it again.

Split by the planner: the open box (forge lag explaining most of forge-ttfb must not make the app's page call the app slow) is #10858; forgeWaited has no caller yet.