[Bug] Bootstrap lock reclaims stale locks non-atomically, allowing concurrent venv rebuilds

[Adolanium]

Affected area

Coding agent and CLI

What happened?

acquireBootstrapLock reclaims a stale lock with rm then mkdir. Two processes can both decide the same lock is stale. One can delete a lock the other just created. Both think they hold it, so two venv rebuilds run at once and can corrupt the environment. This hits on fresh installs and fleet boots.

Steps to reproduce

1. Leave a stale bootstrap lock (dead pid in the lock dir).
2. Start two processes at the same time so both call acquireBootstrapLock.
3. Both return as if they hold the lock, and both rebuild the venv.

Expected behavior

Acquire by creating a uniquely named candidate directory, writing the pid, and renaming it onto the lock path. Rename fails if the target exists. Reclaim a stale lock by renaming it aside before deleting it, so a live lock created in between is never touched. On Windows, treat EPERM as lock-held too. This is the pattern the daemon launch lock already uses.

Prime Agent version

0.7.1 / source as of 2026-08-08

Environment

Windows (directory rename onto an existing target returns EPERM) and POSIX.

Additional context

Original report: #1005

Tested patch, closed in the August 15 backlog sweep: #1006