feat(_internal): Add typed, asyncio-friendly file locking module

[tony]

Summary

• Add FileLock class for cross-platform file locking with context manager support
• Add atomic_init function for race-free initialization (useful with pytest-xdist)
• Support both sync and async usage patterns

Test plan

• Unit tests for FileLock (acquire, release, context manager, timeout)
• Tests for atomic_init with concurrent access simulation
• Cross-platform compatibility (uses fcntl on Unix)

[codecov]

Codecov Report

❌ Patch coverage is 85.71429% with 63 lines in your changes missing coverage. Please review.
✅ Project coverage is 59.98%. Comparing base (d9391c3) to head (1bd57a4).
⚠️ Report is 150 commits behind head on master.

Files with missing lines	Patch %	Lines
src/libvcs/_internal/file_lock.py	69.90%	58 Missing and 4 partials ⚠️
tests/_internal/test_file_lock.py	99.57%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #501      +/-   ##
==========================================
+ Coverage   58.23%   59.98%   +1.74%     
==========================================
  Files          40       42       +2     
  Lines        6489     6930     +441     
  Branches     1098     1130      +32     
==========================================
+ Hits         3779     4157     +378     
- Misses       2177     2235      +58     
- Partials      533      538       +5     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[tony]

Automated review finding. Recorded here so it is not lost. Nothing has been pushed to this branch and no fix is applied — this is a note, not a change request.

Stale-lock removal is time-based only, never checks whether the holder is alive

src/libvcs/_internal/file_lock.py treats a lock as stale purely on mtime age against stale_timeout, and unlinks it. The PID recorded in the lock is never consulted.

Failure scenario: process A legitimately holds the lock for longer than stale_timeout doing real work. Process B sees an old mtime, deletes the lock, and enters the critical section while A is still inside it. Both run the guarded region concurrently — which is the one thing the lock exists to prevent, and it happens specifically under slow-but-healthy conditions rather than crashes.

Suggested fix: before removing, confirm the recorded PID is actually gone:

try:
    os.kill(pid, 0)
except ProcessLookupError:
    pass  # holder is gone; safe to reclaim
else:
    return  # holder is alive; not stale

Note: #502 vendors this file verbatim and carries the same bug.