research: W5 evaluate cooperative Windows lock release #150

Purpose

Follow-up W5 from #122 and merged PR #144. The initial Rust feasibility evaluation is complete; this issue tracks one remaining evidence gate. Windows remains unsupported by the production CLI.

• Scope: find a Windows route that lets the owner release one thread
  without force. Options are an upstream owner-side release (see
  upstream-handoff-proposal.md and section 3.4)
  or a documented cooperative exit of a standalone owner. TerminateProcess,
  taskkill /F, injected console control events and daemon stop_with_grace
  are excluded.
• Evidence: on a disposable CODEX_HOME, with a real Codex binary pinned
  by version and SHA: owner exit or release, actual lock release (reacquire
  under coordination), lock-file state, and transcript hash invariance,
  including concurrent-recovery races.
• Acceptance: a standalone-exit route verifies the same process instance's
  normal exit, actual lock release and transcript invariance. A thread-release
  route verifies the bound thread's actual lock release and transcript
  invariance; the server process may remain alive. Both routes re-probe under
  coordination and reject changing targets or concurrent recovery. A failed
  or unavailable cooperative route never falls back to force.
  Any route exposed through codex-unlock unlock must also preserve its
  same-user, stable completed-idle transcript requirements; endpoint
  authentication alone does not authorize releasing a busy thread.
• Existing coverage: none against a real Codex. Fixture agents exit
  cooperatively on EOF, which only proves that the harness never signals.

Delivery boundary

Use an isolated, unpublished research change with synthetic fixtures first. Record source/binary revisions, environment, hypotheses, actual outcomes and unverified conditions. Keep safeToUnlock=false; completing this gate alone does not authorize recovery or release. No production lock files, real user sessions, host policies or privileges are changed as part of this issue definition.

The proposed architecture keeps the TypeScript CLI. A Rust helper can be reconsidered after W1–W3 establish a concrete need; a full rewrite is deferred. W7 observations are prerequisites for the native classification portion of W3 and for W5; W6 must cover each integrity level claimed. W4 and W5 remain required for any automatic recovery design.

Priority: P2 research gate for recovery.
Milestone v0.4.7 is a planning target, not a Windows support or publication promise.

Source contract: Windows/Rust evaluation.