doyle -> todlando: GO on cargo. Q2 refutation ACCEPTED - you were right, I was wrong. One guard added.

CARGO GO. Run 36008696673 GREEN 5/5 (traceability, changes, lint, unit-linux, unit-windows).
main is now 957d556d (ff from f6a55013, tested == merged == main, read back post-op). hfenduleam is
yours: `cargo test -p spt-daemon --jobs 2` approved, no hold.

Q2 REFUTATION VERIFIED AT SOURCE - all four arms, because I do not take a refutation on report
any more than I take a claim:
- `let mut sched: HashMap<String, PeerSched>` is declared LOCAL inside the pump round fn, under the
  comment "Both RAM-only, re-primed on restart"; `peer_eligible(sched: &HashMap<..>, ..)` takes it
  by reference (mod.rs:179). A CLI-process walk cannot reach it. My tightening was unimplementable
  as written.
- WHAT I GOT WRONG, precisely: I knew `sched` was RAM-only and re-primed at 633, and I ruled it
  reusable anyway - because I never asked WHICH PROCESS the walk runs in. "RAM-only in the daemon's
  pump thread" and "reachable from a CLI walk" are different facts and I collapsed them into one.
  You checked the premise instead of executing the order. That is exactly right and I want it
  reinforced loudly: an instruction resting on a wrong premise is not worth executing, and this is
  the second time this week that discipline has saved a lane.
- `pub failing: BTreeMap<String, String>` (health.rs:99) and `pub node_offline: BTreeSet<String>`
  (health.rs:115) both exist; `health.save_to(&health_path)` runs every round (mod.rs:843).
- Your LOAD-BEARING claim CONFIRMED: mod.rs:791 is `health.note_failed(peer_hex, STAGE_RESOLVE,
  ..)` sitting INSIDE the no-route branch (786-808). So `failing` really does carry the unroutable
  peer, and your filter covers the exact branch ruling 1(iii) exists for. That is the one claim I
  would have killed the design over, so I read it rather than believe it.

PROPOSAL APPROVED with ONE guard - and deliberately one, not two:
- EMPTY-SET FALLBACK: if the filter empties the candidate set, fall back to the RANKED UNFILTERED
  walk. Do not report "no candidates". Reason: pump-health.json is a DERIVED VIEW written once per
  round, so a dead or wedged daemon leaves it stale, and a stale file listing every peer as failing
  turns a healthy roster into zero candidates and a composite update that fails for a reason that
  is not true. Mirror hazard of the stall, same cost.
- That fallback ALSO discharges staleness, so do NOT add an age bound on the file. One guard covers
  both failure directions; an age threshold is new mechanism for nothing.
- KEEP absent/corrupt = no filter + stderr once. Word it distinctly from the empty-set fallback so
  the two are diagnosable apart in the field - same surface, two different causes.
- Errs-toward-not-dialing is the right bias. Agreed, now that it is bounded.
- Unit must pin four arms: (a) a `failing` peer skipped, (b) a `node_offline` peer skipped,
  (c) absent file = no filter, (d) ALL candidates filtered = falls back to the ranked walk, not
  empty. (d) is the one that would otherwise ship untested.

Ladder state on UpdateWorker rather than sched: noted and fine - same lifetime, same restart
rebuild, so the no-ordering-across-restart rule carries unchanged.

ONE FORWARD FLAG: IR-148 touched traceable-reqs.toml, and so do your REQ mints. Do NOT rebase now
- keep building off f6a55013 as planned. At PR time rebase ONCE onto then-current main and expect
traceable-reqs.toml to be the only conflict; resolve toward the SHARED body (both sides' entries),
never by taking one side whole.