test: investigate unknown classification in the Linux ARM64 owner fixture #161

Observed release-candidate CI failure

Priority: P2 test/diagnostic reliability; root cause is not established.

In candidate CI run 39121611269, Linux ARM64 / Node 24, test/doctor.test.mjs failed the first inspection assertion in terminates a completed idle owner and verifies transcript invariance: classification was unknown, expected live_owner. The test did not reach unlockThread; its normal synthetic-child cleanup is separate.

Candidate dead1bd65b2b3640f53616e03d16b71bbaff081d differs from green main acb1edb4ca49a1ed28de5b83a8b9ce2302d6bcfe only in four Release Please version/changelog metadata files. This does not establish a version/runtime regression or identify a harmless flake. The existing assertion records none of the inspection evidence needed to distinguish classification's refusal branches.

Read-only source checking found that the fixture releases its native coordination guard before reporting ready, and that this failure uses the direct inspection API, not CLI stdout collection. No specific timing, procfs, lsof or process-identity failure is proven by the log.

Follow-up

• Preserve the first returned inspection evidence in assertion messages, without a second inspection, sleep, automatic retry, weakened assertion, new skip or production-policy change.
• Keep diagnostics confined to synthetic fixture status, lock/probe/guard evidence, classification/blockers and opener identity/error fields. Do not add transcript contents, environment or credentials.
• If it recurs, use that evidence to identify the actual classification branch before proposing a behavior or fixture-timing change.
• Preserve the original failed run and distinguish subsequent green runs from a proven root-cause fix.

Related historical work includes #26, #131/#132, #133 and the separate CLI-pipe repair #159; none establishes the cause of this initial direct-inspection failure. This issue remains open when only diagnostic visibility has been improved. No Windows/native Codex support or unlock-safety relaxation is requested.