Every response's Server-Timing names the worst event-loop lag of the last 10 s, so a stall outside the handler shows #10288

On the lab today, about one request in six has forge-ttfb of 100–340 ms while the app's own app;dur is 3–6 ms (seen on /nope, /trevato/forge/pulls and /search). Something blocks the event loop between requests, and nothing names it.

Done when:

• [x] A small module (for example src/perf/loop_lag.ts) samples event-loop drift with one unref'd timer every 50 ms and keeps the worst value of the last 10 s. Its cost is under 0.1 ms a tick.
• [x] securityFloor's Server-Timing line, or the existing place that writes app;dur, adds lag;dur=<worst>. /healthz reports it as loopLagMs.
• [x] A test blocks the loop for 150 ms with a busy wait, then sees lag;dur ≥ 140 on the next response, and sees it fall back under 20 within 10 s (with an injectable clock, so the test runs under 1 s).
• [x] The pull quotes the lab preview's lag across 30 requests.

Risks: keep the timer unref'd so tests and shutdown are not held open.

Reviewed pull #10292 at its head: ticked A small module (for example src/perf/loop_lag.ts) samples event-loop drift with one unref'd timer every 50 ms and keeps the worst value of the last 10 s. Its cost is under 0.1 ms a tick.; securityFloor's Server-Timing line, or the existing place that writes app;dur, adds lag;dur=<worst>. /healthz reports it as loopLagMs.; A test blocks the loop for 150 ms with a busy wait, then sees lag;dur ≥ 140 on the next response, and sees it fall back under 20 within 10 s (with an injectable clock, so the test runs under 1 s).; The pull quotes the lab preview's lag across 30 requests..