The flow panel on /boards reads its figures from a short-lived cache, so a /boards load never blocks /healthz #6897

src/web/pages/flow-panel.ts runs readIdlePulls and its other reads on every /boards request, uncached. bun:sqlite is synchronous, so a slow read stops every other request, /healthz included.

Done:

• [ ] The panel's reads go through one cache, the way src/web/studio/home_cache.ts does it: a value that holds while the write clock stands still, and for 30 s at most. It is read only after the viewer's rights are known, and an agent's public-only answer is kept apart from an admin's.
• [ ] /boards renders from that cache. A second load within the window runs none of the panel's reads, and its Server-Timing phase shows it.
• [ ] An HTTP test loads /boards while polling /healthz every 25 ms, and fails if any gap goes over 250 ms. Seed it so that today's uncached panel would fail it.
• [ ] The terminal's Flow screen (src/tui/screens/flow.ts) reads the same cache.

Files: src/web/pages/flow-panel.ts, a new src/flow/panel_cache.ts, src/tui/screens/flow.ts, the test.

Part of the person's incident #6840 (0.7.277 hung the forge). Keep the pull to this one step; both earlier tries bundled everything and failed the check in tests they did not touch (test/mcp-branches.test.ts, the per-account spend ceilings). If the check fails in a test this pull does not touch, name it in the pull rather than widening the change.

Before pushing: bun x tsc --noEmit and the tests you add or touch.

Parked by the crew: the check failed ("the merge queue keeps and names each gate's failing tests > a red gate's two failing tests are kept, logged by name, and answered by the API and the MCP") and the decider saw no point in another try (pull #6914 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.

Parked by the crew: the check failed ("the merge queue keeps and names each gate's failing tests > a red gate's two failing tests are kept, logged by name, and answered by the API and the MCP") and the decider saw no point in another try (pull #6971 closed).

Parked twice since a person last spoke here, so it is the planner's now. Every reason:

1. the check failed ("the merge queue keeps and names each gate's failing tests > a red gate's two failing tests are kept, logged by name, and answered by the API and the MCP") and the decider saw no point in another try (pull #6914 closed)
2. the check failed ("the merge queue keeps and names each gate's failing tests > a red gate's two failing tests are kept, logged by name, and answered by the API and the MCP") and the decider saw no point in another try (pull #6971 closed)

The planner splits it, replaces it with a fresh issue, or defers it; a person can also say what to try. Nothing starts here until then, and the board lists it.

Split into #6973, #6974 and #6975. Both tries went red only in test/merge-queue-gate-result.test.ts ("a red gate's two failing tests are kept, logged by name…"), which this change never touched and which passes on its own on main, 8 of 8. Since then readIdlePulls has been bounded and cached on main (#6912), so what is left is three small steps, one pull each:

1. #6973: the /healthz gap test alone. It is a pin and may already be green.
2. #6974: the rest of the panel's reads go through src/flow/panel_cache.ts, keyed per database rather than in a module global.
3. #6975: the terminal Flow screen reads the same cache.

#6846 now waits on #6974 in place of this one.