security: design Linux descriptor-level flock owner verification #126

Problem

Follow-up implementation design from #100 and its merged research in #115. Supported Linux synthetic measurements show that lsof can exit zero with no warning while a hidden process holds a flock and the only visible process merely has the file open. Existing explicit-warning refusal does not distinguish this case. A wrong-target signal against a real Codex process has not been reproduced.

Proposed scope

Require positive, descriptor-level FLOCK evidence for an eligible Linux candidate, correlated to the same device/inode and revalidated process instance. /proc/locks acquisition PID alone is insufficient: an inherited open-file description can outlive the original acquisition process. This is a Linux adapter proposal, not permission to disable or weaken macOS handling implicitly.

Acceptance criteria

• Finalize a reviewed contract against the pinned Codex acquisition/failure/drop source and the measured cases in docs/research-lock-attribution.md before changing runtime eligibility.
• Bound descriptor enumeration and read size/time. Read and validate candidate FD identity, fdinfo lock evidence, PID/start-time/UID, and target file identity; detect replacement between observations.
• Count only a held matching exclusive FLOCK record, not a blocked waiter or unrelated byte-range record. Do not require the saved acquisition PID to equal a surviving inherited holder's PID.
• Missing, denied, malformed, ambiguous, conflicting, or changing evidence fails closed before any signal. Absence in global /proc/locks never means free.
• Revalidate attribution at the final signal boundary without inserting an await/spawn or carrying the native coordination guard across a signal. Document remaining races and visibility assumptions.
• Use real-lock synthetic tests for hidden holder/visible nonholder, inherited copies, permission/namespace limits, FD replacement and malformed/truncated records; refusals send zero SIGTERM. Preserve normal owner controls and the independent guarded probe.
• A positive inherited FD demonstrates participation, not sole control over all inherited copies. Define how shared-description ambiguity affects eligibility and release verification.
• Keep production JSON/exit compatibility and publish explicit platform evidence/limitations.

Priority: P2 safety hardening. Parent: #100. No real Codex signaling, elevated production diagnostics, native dependency, or Windows support is part of this issue's creation.