doyle — W4 release, with one sequencing correction you must not skip.

Main state: two lanes landed since you last rebased. main is now 79f67567 (657fda0d = #258 IR-147 classifier fix, then 0511877c + 79f67567 = IR-146 (c) docs). Both are CI/docs-only and neither touches product code. You are still sitting on 9aa011ac.

DO NOT branch W4 off main yet. Here is why, and it is a correction to the "branch off current main" default: W4 (#339, feat/339-update-sources) puts source selection into the pump — pinned, then learned, then peers, then channel — and adds --remote / --via-subnet to the composite. W3 (66bf3c00) just rewrote exactly that neighbourhood: 799 changed lines in crates/spt/src/cli.rs, plus propagate.rs, relcache.rs and the peers-first path in adapter add/update. If you branch W4 off main now you write the source ladder against a cli.rs that does not yet have the peer leg, and you eat a real conflict when W3 lands — the bad kind, in the logic you just wrote, not in whitespace.

So, in order:
1. START NOW, no branch: read the W3 diff at 66bf3c00 as your W4 substrate — cli.rs adapter add/update peers-first, wansend.rs pull_adapter_from_peers and adapter_holders, propagate.rs verify_peer_adapter, relcache.rs retain_adapter / retained_adapter / adapter_roster. W4's ladder must SIT ON that, not beside it. Sketch where sources.json is consulted relative to the peers-first path already there.
2. BRANCH when I give you the landed W3 sha. I am gating W3 right now in .worktrees/gate-w3-66bf3c00 against a warm pool; the compile leg is running. You then branch feat/339-update-sources off the landed sha and rebase zero times, which was the whole point of holding you.

One thing already in your favour from my read of W3 so far: the trust gate is in the right place. verify_peer_adapter checks the offered sha256 against the bytes, refuses a signing-key CHANGE outright (a key change never rides a peer), demands a signature whenever a key is declared, and records a trust_anchor; pull_adapter_from_peers stages nothing — the caller stages only what comes back verified. W4 must preserve that property: a learned or pinned source is a HINT about WHERE to ask, never a reason to admit bytes. Do not let sources.json become a trust input. If a pinned source serves bytes, they go through the same verify as a peer's.

Filed while you were handed off, so you do not re-report it: the gh_release finding is now BigscreenVR/spt-bs-releases#343, with the reachability evidence in its first comment. It came out sharper than we had it — the verdict arm in cli.rs is not merely dead for gh_release, its ONLY reachable input is a file_pull whose signing_key fails to parse, which then prints the success line and runs the post-step. Pre-existing, not W3, not yours to fix in this lane.

Reply with your W4 sketch when you have it; do not wait for my sha to start reading.