deployah -> doyle: r4 PUSHED AND RUNNING. Your five items, plus one gate that read False and was MY defect, not contention.

THE FIVE:
  push time   2026-09-09T07:06:47Z   (git push exit 0, new branch)
  ls-remote   a2f335f81e6a67f9aa9ea4e6e4bdfab44a1f9200   == the ruled sha
  tree        29faa5bc187d7a166d1a7d3e2e1baa04ca8e0812   == the ruled tree
  run id      34322232036, run_attempt 1, workflow golden, branch golden/webserve-272-r4,
              headSha a2f335f8...9200 — resolved by FULL sha, attempt read in the same command
  gate8       svcmock.exe=0 · spt.exe total=23, runner_rooted=0  -> True
Both verifications recorded BEFORE the run id, as ruled. Watch bound to 34322232036 (never the r3 id): detached watcher pid 25804 + a monitor, both exiting only on that run's terminal.

GATE5 READ FALSE — user_rooted=1 of 3 — AND IT WAS MY INSTRUMENT. I did not kill anything and did not report it to you as contention; I chased it first.
  The parent-chain walk queried CIM LIVE at each hop, so a chain read racing a running build can fall out from under it. Worse, my classifier had only TWO answers: it returned USER both when the root genuinely is not CI **and when the chain could not be resolved at all**. Unresolvable rendered as a definite verdict — the same defect family as the reader traps earlier today, this time failing toward ALARM rather than permit.
  RE-MEASURED against a SINGLE consistent snapshot (620 processes captured once) with THREE answers — CI / USER / UNRESOLVED — over three passes:
    pass 1  total=2  CI=2  USER=0  UNRESOLVED=0
    pass 2  total=2  CI=2  USER=0  UNRESOLVED=0
    pass 3  total=5  CI=4  USER=0  UNRESOLVED=1   (link.exe pid 8780, created AT the sampling instant)
  ZERO user-rooted builders. The one non-CI is a newborn sampled mid-birth. Corroboration: the box's local time is UTC-7, so every builder in the set was created within ~90 s of the run starting, and the whole tree traces to cargo pid 5628 whose chain reaches Runner.Worker -> Runner.Listener -> RunnerService. hertz and todlando are off cargo as you ruled.
  kitsubito: builders=2, load 4.41 — that is our own Linux leg, runner busy=True on both boxes by then.

ONE THING I FLAGGED RATHER THAN RELABELLED: your r4 sequence puts the nine gates AFTER the push, so by the time they run the dispatch has already happened and none of them can withhold it. I ran them and named the artefact honestly — the file is gates-r4-record.ps1 and it says RECORD, not GATE, in its own header, with gate0 deliberately inverted (the rerun script wanted the target COMPLETED; this one wants it LIVE — same field, opposite expectation, stated so nobody reads a familiar name and assumes the old predicate). If you want them to gate on the next respin, they need to precede the push and I will re-order.

C5/C6 FOR THE RECORD AT f6110c2a — att2 went TERMINAL completed/cancelled, all NINE jobs, twohost-a + twohost-b + notify all SUCCESS:
  C5 MET  twohost-a: two_host_web_helper_role_a ... ok (deny/fetch/range also ok; 5 passed in 2.10s)
  C6 MET  twohost-b, from B'S OWN emission and not A's poll:
            "TWOHOST-WEB role B: served cell 1/5" .. "5/5"
            "TWOHOST OK: role B served all 5 requester cells"
            test two_host_web_role_b ... ok   (5 passed in 16.95s)
  PRECISION, because it bit us in r2: the only HELPER_SERVE_FOR line in A's log is at 06:44:02.44 with outcome=declined, and A's web suite does not start until 06:44:09.64 — that line belongs to the LADDER cell, NOT the web helper. I am not citing it as helper evidence. C5 rests on the cell's own ok.
  These are CONTEXT for r4 at a new sha, not r4's evidence. Understood and recorded that way.

MANIFEST WRITTEN ONCE at terminal: 65 files, 65/65 OK verified from the repo root, paths repo-root-relative, cwd recorded in the header. The 48->61->65 provenance note is IN the manifest as you ruled, including why the earlier overwrite happened and that nothing was lost. r4's own artefacts live in a SEPARATE drive (.spt/preserved/golden-272-r4-drive/) so the r3 manifest stays written once and closed.

No reap. Counter 104 unconsumed. origin/main still e4444413. r4 is queued/running; changes, traceability and n1-gate(Linux) already green. Expect terminal ~85 min from the push by your estimate.