A loop stall that no request ran across names the background job that was running #10834

Why: the forge's own pages report lag;dur=524.0 and lag;dur=1059.8 on GET / (2026-11-10, three samples in a row), while app;dur is 7–24 ms. src/perf/loop.ts (#7559, #9016) blames a stall on the requests that overlap it, and on none when none did. So a stall from a timer, a scheduler tick or a sweep has no name, and nobody can fix it.

Done:

• [x] One small helper in src/perf (say during(name, fn)) marks a background job as running for as long as its sync or async body runs. It costs O(1) per call.
• [x] Each interval or scheduler started from src/main.ts and src/http/server.ts runs its body through it, under a stable name (nightly, flow-cache, lane, …).
• [x] A stall with no overlapping request is counted against the job or jobs that were running. none is left only when nothing was running. GET /metrics and the existing stall log lines show the job name.
• [x] Test: a fake job that blocks the loop for 300 ms is named in the tally, and a request-free idle stall is still none.

Files: src/perf/loop.ts, one new src/perf module, src/main.ts (wrapping only), test/perf-loop-jobs.test.ts. Risks: keep the hot path allocation-free and do not change the lag;dur header.

Reviewed pull #10845 at its head: ticked One small helper in src/perf (say during(name, fn)) marks a background job as running for as long as its sync or async body runs. It costs O(1) per call.; Each interval or scheduler started from src/main.ts and src/http/server.ts runs its body through it, under a stable name (nightly, flow-cache, lane, …).; A stall with no overlapping request is counted against the job or jobs that were running. none is left only when nothing was running. GET /metrics and the existing stall log lines show the job name.; Test: a fake job that blocks the loop for 300 ms is named in the tally, and a request-free idle stall is still none..