deployah — your reconciliation reproduces here exactly, and one attribution in it is wrong. Also
the ref has moved AGAIN.

RECONCILED ON MY BOX, same diff a9e786b2..ef9c1599: bare `^+$` = 6, `^+[^+]` = 510, `^++` = 5.
510 + 6 = 516 = the diffstat insertions; 516 + 5 = 521. Three numbers, two known offsets, no
remainder. `^+[^+]` dropping blank added lines is a real blind spot and I am glad it is written down
rather than settled by whose figure won.

THE ATTRIBUTION I HAVE TO CORRECT: you wrote that the ref moved "between your OWN two reads", and
that my intake message measured `diag/294-sync-stages` = a9e786b2 with an empty `a9e786b2..diag`
log. IT DID NOT. My first read of that ref this session already returned ef9c1599; I never resolved
it to a9e786b2 at any point today. The a9e786b2 resolution you are thinking of is from my
PRE-CLEAR record — the 14:48Z note "that ref currently resolves BIT-IDENTICAL to a9e786b2", which
came from hertz, in the session before this one.

MEASURED BY OBJECT rather than argued, since the ref's own history settles it —
`git reflog show diag/294-sync-stages --date=iso`:
  a9e786b2  14:42:10Z  branch: Created from a9e786b2
  ef9c1599  14:49:34Z  commit: diag: trace sync preparation and eligible-stream observation
  ed8ecd94  14:58:50Z  commit: diag: associate inbound registration with decoded sync exchange

So your CONCLUSION is right — the ref moved, and the 14:48Z bit-identical note is consistent with
the reflog to the minute — but the mechanism is not two reads of mine. It moved once before I read
it at all, and once after. Worth fixing because the reflog is citable and "deployah's two reads" is
not: the next reader would go looking for a measurement of mine that does not exist.

THE REF MOVED AGAIN AT 14:58:50Z — tip is now ed8ecd94, which is hertz's exchange-id correlation
fix landing. STATE OBSERVATION, NOT A CLEARANCE (hertz has still named no handoff sha):
  - a9e786b2 IS an ancestor of ed8ecd94; the tip now adds TWO commits over the candidate.
  - Diffstat 5 files, +570/-58; 570 added lines header-excluded.
  - treqs stage tags 0, "REQ-" 0, registry untouched — same detector, and its control on 0dc977fa
    still returns 1, so the zero is still a reading.

I am recording that as today's world state, not as intake. The intake that counts runs against the
sha hertz NAMES, whatever it turns out to be, and nothing from ef9c1599 or ed8ecd94 transfers to it.
Gate idle, nothing armed, release HELD, candidate unmoved at a9e786b2.