No concurrency guard on the shared per-repo base clone lets concurrent attempts race git fetch/checkout/reset --hard

[JSONbored]

Context

packages/loopover-miner/lib/repo-clone.js:87-120 (ensureRepoCloned) resolves one deterministic path per repoFullName and mutates it in place with no locking: git fetch origin, git checkout <baseBranch>, git reset --hard origin/<baseBranch>. worktree-allocator.js's acquire() enforces only a total active-slot count (maxConcurrency, default 2) with no per-repoFullName exclusivity, so two different attemptIds for the same repo can both hold an active slot and both call ensureRepoCloned concurrently — a genuine git-level race (index/HEAD/ref corruption or spurious .git/index.lock failures). test/unit/miner-repo-clone.test.ts has no test containing "concurrent", "race", "lock", or Promise.all.

Requirements

• Serialize ensureRepoCloned calls that target the same resolved repoPath (in-process keyed mutex/queue, or a filesystem lock file honored across processes).
• Alternatively/additionally, make worktree-allocator.js's acquire() reject/queue a second concurrent allocation for a repoFullName that already has an active slot.

Deliverables

• Serialization for ensureRepoCloned per resolved repo path
• Regression test running two concurrent ensureRepoCloned/prepareAttemptWorktree calls against the same fixture repo, asserting no corruption/lock-contention failure

Test Coverage Requirements

99%+ Codecov patch coverage on every changed line and branch, plus a regression test that reproduces the exact failure mode described above and asserts it's fixed.

Expected Outcome

Two concurrent attempts on the same repo never run git commands against the shared base clone simultaneously.

Links & Resources

packages/loopover-miner/lib/repo-clone.js:60-63,87-120, packages/loopover-miner/lib/attempt-worktree.js:63,75, packages/loopover-miner/lib/worktree-allocator.js:20,186-218.

[linear-code]

JSO-4576