dashboard-switch-speed: say which check failed; keep a shown Board when one fresh read fails (rare flake) #639

Outcome: When dashboard-switch-speed fails, it says which check failed. And if the cause is the Board dropping a board it already showed when one fresh read fails, the Board keeps that board on screen, marked stale.

Why (measured, investigation 2026-10-18):

• The gated test "an instance switch and a page switch from cache each show the new view's own data in under 300 ms" fails rarely on busy's Board after its fresh answer (test/dashboard-switch-speed.test.ts:294).
• Seen on 2026-10-15 (run 38801971309, a branch with none of the later merge wave), on PR web: Needs you is one queue at /needs-you, blocking first then oldest; its badge counts Waiting on you (#585 part 2) #627's head (run 39104300919) and on PR No vendor attribution: agents run with it off, push gate and PR-body check refuse it [PROTECTED: owner merges] #619 (run 39105035460). Over the last 91 ci.yml runs: 0 in about 140 runs of the test before the 2026-10-18 merge wave, 2 in about 42 after, so it's a pre-existing low-rate flake. All main push runs passed.
• After quiet() the test checks boardOf(to) once: busy's Board has at least one card, every card is busy's, at least one card is fully visible, and busy's switcher row is the only one with aria-current. The failure output doesn't say which check failed, so two builders have guessed at the cause.
• Likely mechanism (inferred, not reproduced). BoardPage (web/src/pages/Board.tsx, loadBoards and its effect, ~400–435) turns a failed fresh /board answer into {data: null, error}. That replaces the cached board with "can't load its board" and zero cards until the 15 s tick. useView in web/src/api.ts keeps old data on a transient error instead. A loaded runner, with four dashboards and the hub in one Node process, could produce such a blip.

Constraints:

• Step 1, test only: on a false boardOf, report the card count, the set of card instances, whether any card is visible, the aria-current row text, any board-instance-error text, and whether "updating" shows. Do the same for the relay test's swallowed failure. Don't loosen SWITCH_MS or COLD_MS, and don't wrap the assertion in a retry.
• Step 2, only if the evidence points at it: keep the board already on screen for an instance whose fresh read fails, marked stale, as useView does. Add a regression test where a fetch failing after a kept board leaves the cards shown.

Deliverable:

- test: test/dashboard-switch-speed.test.ts
- command: |
    npm run typecheck

Review point: L1 (web/** and test/**, not protected). The evaluator approves.