TWO MEASUREMENTS, THEN MY CALL. Both measurements bear on things three of us have now asserted from
memory rather than from the timeline.

=== 1. CONTENTION ON THE RECORD RED'S WINDOWS LEG: REFUTED AT JOB LEVEL, WITH ITS SCOPE ===
doyle withdrew this from his own recollection; here is the actual timeline, so it is settled rather
than merely withdrawn. Run 34445961595, all timestamps from the jobs endpoint:
  test (Windows, hfenduleam)   06:44:27Z -> 07:18:59Z   FAILURE   <- the red
  n1-gate (Windows, hfenduleam) 06:36:53Z -> 06:44:25Z  success   (ended 2 s BEFORE test started)
  twohost-b                     07:19:02Z -> 07:36:16Z  failure   (started 3 s AFTER test ended)
  twohost-a                     07:48:07Z -> 08:13:18Z  failure
I also checked for a FOREIGN run on the box, which nobody had: ci 34446095808, pull_request, THE SAME
SHA a9e786b2, was live 06:38:13Z -> 07:48:06Z and overlaps the red's window at RUN level. Its Windows
job does not:
  unit (Windows, hfenduleam)    07:19:01Z -> 07:48:05Z  cancelled (started 2 s after the red ended)
So ZERO GitHub jobs ran on hfenduleam during 06:44:27-07:18:59. Every Windows job in both runs
abuts its neighbour by 2-3 seconds, which is serialization, not coincidence.
SCOPE, because this is the part that would be easy to overclaim: this refutes GITHUB-JOB contention
only. It says nothing about non-GitHub load on that box in the window — local agent builds, an
editor, Defender — and gh cannot see any of it. "The box was busy" is NOT excluded. "Another CI job
was running" IS.
It also means the twohost VARIABLE could not have acted through concurrency on the test job at all:
twohost-a/b are `needs: test` (golden.yml:1035, :1213) and materialize after it. And inside the test
job's own body (:88-810) there is no `inputs.twohost` reference — the only `twohost` strings there
are binary NAMES inside the HEAVY filter, present at either input value. The input changes which
JOBS exist, not how the test job runs.

=== 2. EVENT IS NOT AN UNCONTROLLABLE VARIABLE — golden's push trigger is a golden/** ref ===
This is the one that changes the next arm. golden.yml:7-9 at the sha:
  on:
    push:
      branches: ['golden/**']
    workflow_dispatch:
      inputs: { twohost: { type: boolean, default: true } }
The record run was event=push on branch golden/crossnode-294. So event=push is REPRODUCIBLE at will:
push the same OBJECT to a NEW golden/** ref. And on the push path the twohost jobs run
unconditionally — the guard is `!cancelled() && (github.event_name != 'workflow_dispatch' ||
inputs.twohost)`, so push satisfies it without any input.
That makes a push-to-golden/** arm at a9e786b2 reproduce the record's WORKFLOW CONFIGURATION
exactly — same sha, same event, same twohost job set, bare tree — where a workflow_dispatch
twohost=true run would still differ in event. doyle is right that this restores configuration and
NOT prior machine state; I am not claiming otherwise, and I am not promising it classifies anything.

=== MY CALL, as the lane that owns golden runs ===
I AM FIRING IT, and the reason is the gate, not the diagnosis. The release gate REQUIRES a
clean-candidate FULL-twohost green on a9e786b2 before core#218 merges. That run has to happen
whatever Finding 1 turns out to be, so this is not a speculative spend, and firing it as a push to
golden/** costs exactly the same as the dispatch variant while controlling one more variable.
Method, per the branch hazard: push the OBJECT, `git push origin a9e786b2...:refs/heads/golden/
crossnode-294-r2`, then verify ls-remote sha AND tree against a9e786b2 and record both BEFORE I
record a run id. A hand-moved branch name is a snapshot of the last assembly it was moved to, and I
am not pushing a name.
TIMING: not yet. Arm 2's n1-gate (Windows) is still in_progress on hfenduleam, and golden's
concurrency group is per-ref, so a new ref would not queue behind it — it would CONTEND for the
Windows runner. I fire when 34474627303 is terminal.
WHAT I WILL AND WILL NOT SAY ABOUT THE RESULT: a green is release-gate evidence and n=1 against
Finding 1. A red at the record's own conditions is a reproduction and worth far more than another
bare arm. Either way I report cell rows with the Summary control first, and classification stays
doyle's.

=== CARRIED ===
doyle's classification — Finding 1 UNCLASSIFIED, recorded as a gap rather than forced — goes into
PROVENANCE.md beside the preserved logs verbatim, as he asked. Release HELD, v0.69.0 not cleared,
core#218 unmerged, no tag, no publish, no board work, budgets unchanged. 34445961595 remains the
verdict of record until a run at its own conditions says otherwise.