research: W4 establish Windows lock-holder attribution #149

Purpose

Follow-up W4 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: decide whether a positive holder for a LockFileEx lock can be
  established at all. Candidate sources are Restart Manager, handle
  enumeration (which may require privileges that are out of scope) and
  owner-side cooperation from upstream.
• Evidence: records showing that a candidate set contains the holder and
  excludes non-holder openers, the prober and the orchestrator, in the same
  forms as E3.
• Acceptance: without positive single-holder evidence the result stays
  unknown for an opener-targeted action. An opener list is never promoted
  to holder evidence. An authenticated owner-cooperative design must instead
  prove its endpoint, thread and owner binding under a separately reviewed
  contract; it is not implicitly authorized by an opener list.
• Existing coverage: E3 opener_candidates_only records.

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.