Docs point at a deleted Windows schtasks job; nothing records which host runs the dispatcher nf-u3s ← Beads

Twinned from https://github.com/cfsh/ninefold/issues/612 by tools/beads/import_github.py's reconcile pass.

The Windows ninefold-reviewer-dispatch scheduled task was deleted on 2026-08-06 (Aedan is winding that box down). The dispatcher now runs only on the Linux VM, from cron at 2,32 against ~/nf/agents/ninefold-reviewer. Several docs still send readers to a job that no longer exists on any machine:

• CLAUDE.md — the WAKE: STALE-DISPATCH row tells every session to *"Check the ninefold-reviewer-dispatch schtasks job"*. This is the alarm the file ranks above everything else, so its remedy pointing at a deleted Windows task is the worst instance of the problem.
• notes/reviewer.md and tools/reviewer/README.md — carry the same Windows framing for deployment and retirement.
• DEVEL.md §"Tier-0 reviewer credentials" — documents ~/.secrets/ and ~/agents/; the ~/nf boxes use ~/nf/.secrets/ and ~/nf/agents/, and since #578 app_token.py searches the ~/nf one first. Already noted on #590.

⚠️ Worth more than a path fix — the two dispatchers were both running. schtasks /Query immediately before deletion reported Status: Running, so for some hours two hosts were sweeping the same global PR queue, each able to post verdicts and set labels on the same PRs. Nobody decided that; the VM's was set up because a complete box has one, and the old one was never turned off. DEVEL.md already warns *"don't stand up a second one without deciding that two sweepers racing is what you want"* — the warning was there and could not be acted on, because nothing anywhere records which hosts run a dispatcher. A singleton with no registry is a singleton by luck, and the failure mode is silent: duplicated or flip-flopping verdicts, never an error.

So this probably wants two things: correct the paths, and give the singleton something that makes a duplicate visible — the heartbeat already carries a sha and could carry a host.

Unclaimed.