Add cross-platform file lock for concurrent venv installs (parity with JS bootstrap)

[ar7casper]

Context

When openant is invoked while another openant invocation is already running, two concurrent pip install -e <core> calls can race on the same ~/.openant/venv/. pip is not safe under concurrent installs to the same environment — typical failure modes include corrupted RECORD files, partial wheel extraction, and broken .dist-info metadata.

Two related code paths today have inconsistent treatment of this concurrency problem:

• JS parser bootstrap (fix: lazy-install JS parser npm deps on first use #37): implements a cross-platform file lock at parsers/javascript/.openant-npm-install.lock using msvcrt.locking on Windows and fcntl.flock elsewhere. Concurrent JS scans serialize cleanly.
• Go-side venv install (feat: auto-detect dependency changes and reinstall openant #36): documented as a "Known limitation" in apps/openant-cli/internal/python/runtime.go::CheckDepsStale. No lock. The stated rationale was that Go's stdlib doesn't have a portable flock equivalent on Windows.

The gap

For users with even simple parallel workflows (e.g. openant scan A & openant scan B, or two terminals doing openant parse <repo> simultaneously), the venv install path can race. JS bootstrap is safe; venv install is not.

Proposed approach

Add a Go-side file lock around the pip install -e call in CheckOpenantInstalled and CheckDepsStale. Two candidate implementations:

1. golang.org/x/sys/unix.Flock + golang.org/x/sys/windows.LockFileEx — direct OS calls, portable behind a build-tag wrapper.
2. github.com/gofrs/flock — third-party, cross-platform, ~200 LOC of dependency.

Option 1 aligns better with the "no extra dependencies" preference but requires platform-specific Go files. Option 2 is one import.

Lock target: ~/.openant/venv/.deps-install.lock. Same acquisition pattern as parsers/javascript/_file_lock (block-until-acquired, re-check sentinel inside lock).

References

• apps/openant-cli/internal/python/runtime.go — CheckDepsStale and CheckOpenantInstalled are the call sites needing the lock
• libs/openant-core/parsers/javascript/test_pipeline.py::_file_lock — reference impl
• feat: auto-detect dependency changes and reinstall openant #36 (deps-hash auto-reinstall) — established the codepath where the race lives
• fix: lazy-install JS parser npm deps on first use #37 (JS lazy install) — established the file-lock pattern for the analogous npm race

[gadievron]

Substrate for this, plus one residual a lock alone would not close — found while auditing a full
end-to-end run that re-pointed the shared venv.

Where it happens. apps/openant-cli/internal/python/runtime.go: venvDir (:36) resolves the
single shared venv; EnsureRuntime (:219) drives setup; depsHash (:292) keys staleness on the
resolved corePath; checkDepsStaleWith (:328) compares it; installOpenant (:385) reinstalls
editable when it differs. Keying on corePath is deliberate and is the anti-contamination mechanism —
pointing the venv at whichever clone is running is what stops a stale sibling's code being used.

This issue's exact gap is stated in the source. runtime.go:345-347 names the concurrent-install
race verbatim, which is what a cross-platform lock would fix.

The residual. A lock serialises the install, but the mutation is process-global for its whole
duration: the .pth in the shared venv points at one clone, and mid-scan child interpreters resolve
openant through it — e.g. core/parser_adapter.py:813 and core/reporter.py:664 spawn Python
subprocesses during a scan. If a second session re-points the venv while the first is mid-run, the
first session's later child interpreters import a different checkout than its own parent process
did, with no error and no signal in any artifact. A lock around the install does not prevent that;
either the venv needs to be per-clone, or a running scan needs to detect that the .pth moved.

On our run the live .pth named the running clone's path 7 times (7 editable reinstalls) — normal
pip/hatchling behaviour, noted only so the file's shape isn't mistaken for damage. I did not observe
the cross-session skew; it is a source-level reading of what the shared mutation permits, offered as
scope input for whichever fix you take.

[gadievron]

Forward pointer: the residual described in my comment above — the mid-scan .pth re-point, which a
lock around pip install -e would not address — is now filed separately as #303. This issue's
scope is unchanged.