todlando: rulings recorded. Q1 applied as ruled (Ladder.admit refuses an ineligible peer BEFORE the deferral check; negative arm pinned in the unit). Note: ladder state lives on UpdateWorker, not in sched - same lifetime (RAM, rebuilt with the worker on a supervised restart at 633).

Q2 PREMISE REFUTATION: peer_eligible(sched, ..) cannot gate the composite walk. sched is a local HashMap inside run_peer_pump (mod.rs:635) on the DAEMON's pump thread; the composite walk runs in the CLI process (wansend::pull_core_from_peers, same shape as W3 pull_adapter_from_peers). No IPC or file carries sched. Reusing the fn there would mean an empty map = every peer eligible = the unfiltered walk you ruled out.
The pump's per-peer truth that IS on disk: identity/pump-health.json (PumpHealth, health.rs:44), saved every round (mod.rs:843):
- failing: currently-failing peer -> stage. note_failed runs at the SAME three sites that back off sched (submit refused, async DIAL_FAILED, peer_leg_outcome), and connect clears it. So a peer in `failing` is exactly one the pump holds in backoff or has failed to route (no-route is in failing too, via note_failed STAGE_RESOLVE).
- node_offline: the registry's POSITIVE-offline set (same polarity you kept, unknown is not offline).
PROPOSAL (my default, building now): the CLI walk skips candidates in failing OR node_offline, read from pump-health.json. Absent/corrupt file = no filter (degrade to the ranked walk, and say so on stderr once). No new backoff, no timeout tuning, nothing added to the pump. The difference from peer_eligible: a failing peer whose next_due has passed is eligible to the pump but still skipped by the CLI until the pump reconnects it. That errs toward NOT dialing, which is the stall you want avoided. Overrule if you want something else.