Taken as step-level, and I am not converting it. Cell rows OWED. Three things I can add that are
measurements, plus one correction of attribution.

1. THE PHASE-A MEMBERSHIP CLAIM IS STRONGER THAN "deployah's HEAVY-filter read", and you should have
the basis rather than my say-so. Two independent legs, neither of them an inference:
   - HEAVY is ONE job-level env at the sha (golden.yml:158), a binary()-name filter, and it is the
     SAME string for both OSes; Phase A is its exact negation (:457 bash, :464 pwsh, both with
     --no-fail-fast). Neither `sync` (spt-daemon) nor `contract_e2e` (spt) appears in either
     binary() list, so both cells are Phase A by the filter on both platforms.
   - DIRECT WINDOWS EVIDENCE ALREADY EXISTS, from arm 1's own log: the sync cell ran (1993/3346) and
     the contract cell (36/3346) — both Phase A ordinals on WINDOWS. So Phase A being the right step
     to watch on Windows is measured at arm 1, not derived from the Linux run.
   It still does not license the cell sentence for arm 2. A green step remains consistent with a
   cell being unselected or skipped, and the population count is only in the log.

2. WINDOWS STEP TIMINGS, arm 2 (from the job's steps, not the log):
     Build workspace fixture binaries   12:05:37Z -> 12:12:50Z  (7m13s)
     Phase A — windows                  12:12:50Z -> 12:34:37Z  (21m47s, STEP WALL)
     Phase B — windows                  12:34:37Z -> running
   21m47s is a STEP wall and is NOT the same quantity as arm 1's Phase A Summary [786.355s]. I am
   not differencing them.

3. BUDGET ARITHMETIC, because this job has been killed by its wall before and a wall kill reports as
   `cancelled`, never `failure`. The `test` job's budget at this sha is timeout-minutes: 80
   (golden.yml:172, inside the test block that opens at :88; the 40s belong to n1-gate/twohost).
   Job started 12:04:26Z, so the wall is 13:24:26Z. The workflow's own comment records v0.68.0 r3
   att2 needing ~56 min with Phase A 17m14s / Phase B 20m25s. This arm's Phase A is 21m47s, i.e.
   ~4.5 min longer than that reference. There are 28 steps after Phase B (doctests, clippy both OS
   arms, notify E2E, installer E2E, docs drift, docs bundle, dormancy, disk floors, reaps). If the
   tail behaves like that reference the job lands ~13:05Z with ~19 min of margin. That is a
   projection from one prior job on a different sha, not a prediction, and I will report the actual.
   If it DOES hit the wall the conclusion will read `cancelled` and the Phase A cells will still be
   readable from the log — a wall kill does not cost us the rows already printed.

CORRECTION OF MY OWN ATTRIBUTION, since you listed it in the ledger: my Linux report said arm 1's
Linux red cell passed here at 3.629s. Keep the limit attached to it — the exact-once assert compares
(kind, author) and both expected rows are ("MSG_IN", Some("alice")), so two backlog rows satisfy it.
That pass does not establish both relay arms published, and it is a different tree from the arm that
reddened. Your "delayed vs absent publication" is still open and this green does not narrow it.

Nothing in your five-row ledger is a controlled comparison and I am not treating it as one. Release
HELD, classification OPEN, 34445961595 the verdict of record. I will pull the Windows log the moment
the JOB is terminal and score Summary-count first.