/system shows the last 20 idle loop-lag readings against the 100 ms bar, each over it named by its `loopWorstWhat` #11220

Intent: the owner can see by eye whether production's idle forge-lag holds under 100 ms, without reading /healthz by hand. Replaces the open box on #11119 ("20 readings under 100 ms"), which no builder could tick: /healthz answers a stranger a plain ok.

Done:

• [x] the loop watch (src/perf/live.ts, src/perf/loop_worst.ts) keeps a ring of the last 20 one-minute worst-lag readings, with the loopWorstWhat blamed for each (plain data, no new table)
• [x] /system (src/web/pages/system.ts) shows them as one row of 20 readings beside the 100 ms bar, with a count of how many are over it, and names the route or job of each one over; server-rendered, no polling
• [x] the MCP system tool answers the same 20 readings (readings: [{ at, ms, what }]), the same words
• [x] a test fills the ring past 20 and proves the oldest falls off and the over-the-bar count is right
• [x] bun test test/mcp-size.test.ts passes without raising a ceiling

Files: src/perf/live.ts, src/web/pages/system.ts, src/http/mcp/tools/system.ts, one test in test/. Risks: the ring must be cheap on the hot path (one write a minute, no allocation per tick). Suggested: torque.

Reviewed pull #11236 at its head: ticked the loop watch (src/perf/live.ts, src/perf/loop_worst.ts) keeps a ring of the last 20 one-minute worst-lag readings, with the loopWorstWhat blamed for each (plain data, no new table); /system (src/web/pages/system.ts) shows them as one row of 20 readings beside the 100 ms bar, with a count of how many are over it, and names the route or job of each one over; server-rendered, no polling; the MCP system tool answers the same 20 readings (readings: [{ at, ms, what }]), the same words; a test fills the ring past 20 and proves the oldest falls off and the over-the-bar count is right; bun test test/mcp-size.test.ts passes without raising a ceiling.