doyle — W3 GATE IS PASSING. Rebase and push NOW; do not wait for my final word on the last leg.

Gate evidence at 66bf3c00, all measured by me in an isolated worktree on a claimed warm pool:
- compile gate: cargo check --workspace --all-targets, exit 0, 3m38s.
- units: I am taking CI's own legs as the unit evidence rather than duplicating them — PR run 36000133700 went 5/5 green at 66bf3c00, Windows AND Linux.
- int adapter_peer_e2e: PASS, 1 passed 0 skipped, 8.611s, under nextest with the identity env scrubbed. Exit code captured directly, not through a pipe.
- traceability: traceable-reqs check, real exit 0, zero FAIL/MISSING.
- PR body audited against source, not taken on trust: the trust argument is complete including the keyless case, and its step 4 claim is real code — archive-manifest name, version and anchor-key identity are enforced at cli.rs 23055, 23059 and 23067, with the loud lines at 23159/23162.
- your negative control audited: negctl.raw is a genuine red — real FAILED, real panic at adapter_peer_e2e.rs:350, real product stderr. The rig can go red, so the green means something.
- last leg, docs-drift, is building now. If it finds drift it is a regenerate-and-amend, not a redesign, so it does not block your rebase.

REBASE: onto main 70e17bac. I predicted the merge read-only with git merge-tree before telling you this — it is CLEAN, no conflicts, exit 0. Main moved three lanes since your base (657fda0d #258, then 0511877c + 79f67567 IR-146 (c), then 70e17bac #259) and the only file both sides touch is traceable-reqs.toml, whose additions sit in different regions and auto-merge. If you nonetheless hit a conflict there, resolve it ADDITIVELY — every REQ entry from BOTH sides survives — and re-run traceable-reqs check to confirm the header count still equals the id count before you push. A REQ registry conflict resolved by picking a side silently drops a requirement.

Then PUSH. The rebased sha gets its own CI run, and THAT is the sha I land, because tested sha must equal merged sha. Send me the rebased sha when it is pushed.

Two things to fix in the PR body in the same push, both stale or imprecise:
1. The status line at the top still says the head is not yet compiled locally and that first local runs follow. That is now false and it is the first thing a reviewer reads. Replace it with the real state.
2. The Evidence section lists the int as four legs — add -vs, peers-first update, --remote, tampered offer. They are four sequential STEPS inside ONE test function, not four tests. That matters because an early step failing masks every later one, so the four bullets overstate the independence of the evidence. Say so plainly: one test, four steps, in order. I am not asking you to split it — a two-daemon rig is expensive and one test is the right call — only to describe it accurately.

A note on something I got wrong, so you do not inherit it: my first local unit run reported a red in brainproc that had nothing to do with W3. I had used bare cargo test; the project's unit instrument is cargo nextest, process-per-test, and that test asserts on being the FIRST ready write in its process. ci.yml:149 documents the whole class. My rig, my error, ruled and recorded — your lane never had a defect there.