A determinism test reports 'not deterministic' when it actually could not measure determinism

[pseudoseed]

What happened

spec-1280-measurement-instrument.test.ts → T12 determinism — emits byte-identical output twice at the same commit failed during a full suite run on 2026-08-29. The two invocations recorded
different commits:

Commit: a725af68f (first invocation)
Commit: 4ebaf36b6 (second invocation)

A porch done ran at 14:57:53 while the suite had been running since 14:56:03. Porch wrote its
state commit between the instrument's two invocations, so HEAD moved underneath the test.

The instrument is deterministic. Nothing was wrong with it, and nothing was wrong with the change
under test. Re-running the file with HEAD stable passes.

The actual defect

The test's own name states its precondition — at the same commit — and the test never checks
that the precondition held. So when HEAD moves, it reports "output was not byte-identical",
which is indistinguishable from a genuine non-determinism bug in the instrument.

That is the failure mode this repo already has a rule against:

"I could not tell" must never be spelled the same way as "no". A truncation, an unreachable
API, and a server too old to answer each need their own signal.

Here, "the instrument is non-deterministic" and "I was not in a position to measure
determinism" produce the same red, with the same message. Someone hitting this at 21:00 spends
their time hunting non-determinism in an instrument that does not have any.

It is the same shape as the leak in #214 and the CI-build guard in #209: something reporting a
value it was not positioned to observe.

Fix

Read HEAD before the first invocation and after the second. If it changed, fail (or skip) with
a message that names that — "HEAD moved from X to Y during this test; determinism was not
measured" — rather than reporting a diff. The two outcomes must not share a signal.

Capturing the SHA once and passing it to both invocations would make the runs comparable, but it
would not be enough on its own: the working tree can still change under a running suite. The
guard has to be able to say it could not tell.

Operational hazard, worth recording either way

Running a porch command while a full suite is running can turn this test red for reasons that
have nothing to do with the code under test. Porch commits state, state commits move HEAD, and
this test reads HEAD twice. Anyone who sees this failure should check whether something committed
during their run before investigating anything else.

Found while fixing #216; not fixed there, to keep that PR to its subject.