fix(coding-agent): acquire the bootstrap lock with an atomic rename

[Adolanium]

Fixes #1005.

What was broken

acquireBootstrapLock reclaimed a stale lock with rm(lockDir) and then retried mkdir. Two processes can both judge the same lock stale, and one process's rm can delete a lock directory the other just created, with the loser's pid write landing inside the winner's directory. Both then return believing they hold the lock, so two venv rebuilds run concurrently and can corrupt the environment. Fresh installs and fleet boots are where several processes start together.

The fix

Adopts the pattern the daemon launch lock and session leases already use: create a uniquely named candidate directory, write the pid file inside it, and atomically rename it onto the lock path (rename fails if the target exists). Stale reclamation renames the lock aside before deleting it, so a live lock created in the interim is never touched. One wrinkle: Windows fails a directory rename onto an existing target with EPERM rather than EEXIST, so that is treated as a lock-held signal too.

Signature and staleness semantics are unchanged.

Testing

• New regression file test/suite/regressions/1005-bootstrap-lock.test.ts: concurrent acquires serialize, a dead-pid lock is reclaimed with no leftover candidate or stale dirs, and a live lock injected between the stale rename-aside and the delete survives untouched.
• npx tsx ../../node_modules/vitest/dist/cli.js --run test/suite/regressions/1005-bootstrap-lock.test.ts test/kernel-bootstrap.test.ts: the 3 new tests pass; the 17 kernel-bootstrap failures reproduce identically on unmodified main (the suite's fakes are POSIX-only shell scripts that cannot spawn on Windows).
• npm run check clean.

Note

Fix acquireBootstrapLock to use atomic rename preventing concurrent venv rebuilds

• Rewrites lock acquisition in bootstrap.ts to use an atomic directory rename: creates a UUID+PID candidate directory, writes a PID file, then renames it to the lock path atomically.
• Fixes a race where stale lock reclamation could delete a newly created lock from another process; now renames the stale lock aside before removing it, ignoring ENOENT if it disappears.
• Adds isLockDirExistsError to handle EEXIST, ENOTEMPTY, and Windows EPERM as lock-exists conditions during rename.
• Adds regression tests in 1005-bootstrap-lock.test.ts covering concurrent acquires, dead-process reclaim, and the live-lock-during-reclaim edge case.

^{Macroscope summarized cf38413.}

[sethkarten]

Thank you for the report and proposed work. This root cause is now covered by maintainer-owned stacked PR #1161, authored independently from upstream/main.

We did not inspect or reuse this PR's diff, branch, commits, implementation code, or tests; its public description/comments were used only as a bug report. To keep one review surface, this PR is superseded by #1161 and is being closed.

The complete review stack is #1158–#1165. It is being left unmerged for human review after CI and review-bot findings are cleared.