The proof layer's gone-owner boundary fails intermittently on macOS — and a boundary that moves under load may fall toward a positive verdict

[fujibee]

an owner whose process is gone is undetermined, not a proof about it (#1152)
fails intermittently on macOS, across unrelated pull requests.

Observed twice in one session, on two different branches and two different
shards, with no shared content:

bats (macos-latest 4/5)   a windows-handshake test change
bats (macos-latest 5/5)   a documentation and driver-entry change

Neither branch touches the proof layer. ubuntu passed both times.

This is filed as more than housekeeping because of what the test asserts. The
proof layer answers with four states, and this test pins the boundary between
two of them: an owner process that is gone must come back undetermined, not
as a proof about the pane. If that boundary moves under load, the failure
mode is not a red build — it is a proved that was never established, handed
to a caller that will write on the strength of it.

So the question this issue asks is not "why is the test flaky". It is:

• does the classifier depend on timing anywhere between observing the owner
  pid and reporting the state, and
• if the observation races, which way does it fall — toward undetermined
  (safe) or toward a positive verdict (not safe)?

A test that flakes toward red may be sitting next to a path that flakes
toward a false positive. That is worth measuring directly rather than
inferring from the red.

Related: the combined-run diagnostics recently added to this suite print the
inner failures instead of discarding them, so the next occurrence should
carry more than a terminated sleep.

[fujibee]

Closing: the boundary now holds by construction, not by timing.

Where: PR #1191, head 3ab82d809d3ec12cea27b480bf04b51bc096e4ea, squash-merged into integration/terminal-driver-v1 as 532a60f4cdedc55f15122a376e001ca31a418a54 (2026-09-13T09:24:20Z). File: scripts/lib/self-proof.sh (after liveness says alive, the proof requires the owner's instance marker); test tests/test_self_proof.bats — "an owner pid that is alive but has NO instance marker is undetermined, never a proof (#1187)". That test was red before the change (the classifier answered proved) and is green at the head above; removing the marker requirement reddens it alone.

What was measured (against the suite's own fixture, before the fix):

owner pid	marker	ancestry	verdict
alive stranger (sleep)	none	two edges, not reaching the root	undetermined invocation_ancestry_truncated
alive stranger	none	complete, containing it, pane process in it	proved
the test shell itself	none	complete	proved

So the intermittent macOS red was the visible edge of a real defect: liveness was judged once from kill -0 plus a marker whose absence counted as alive, and with a complete ancestry a pid nothing tied to the session was proved. The CI runs that landed on undetermined did so because the fixture's fake ancestry stopped short of the root, not because the classifier held.

After the fix: absent marker → undetermined owner_marker_absent; unreadable or half-written → undetermined owner_liveness_unknown; a marker naming another session never reaches proved. The lock's own default (absent marker = alive) is unchanged there, where reclaiming would be the harm; the two contexts no longer share a default, and the call site says why.

The flaky test also checks its precondition now: if the reaped pid is found alive again before the read, it skips by name rather than measuring a stranger. The load-dependent direction was toward a positive verdict, which is why the requirement sits on the proof side.