Remove obsolete legacy file-lock reclaim branch from withLocalLock

[devin-ai-integration]

What and why

withLocalLock (src/local-ai-install.ts) only ever publishes the ${name}.lock path as a directory (mkdirPrivate(candidate) + renameSync), and has since the file was introduced in 2.8.0. The if (stat.isFile()) { unlinkSync ... } branch inside the stale-reclaim path handled a "legacy file lock" shape nothing in the repo produces. Removed it; the tombstone-rename reclaim that follows already handles any stale entry (including a file), so behaviour is preserved. Nothing else becomes unreferenced.

Dead-code scan finding sfind-5da91d2c66074c3e89672a9c8f8a52b3.

Checklist

• bun run release:check passes locally — ran lint, typecheck, build, and test:unit instead: all green except the two native * archive tests in tests/node/chromium-package.test.ts, which fail identically on a clean main (hashlib.file_digest missing in this box's Python), unrelated to this change.
• Locally launched browsers and Electron attachments stay on the guard proxy — unrelated.
• No secret value reaches the model sandbox — unrelated.
• Dependency pins are still mirrored everywhere — no version changes.
• Public API changes update types/*.d.ts — no public API change.
• CI job names unchanged, no new actions.
• No unit test imports src/worker.ts directly — no test changes.
• CHANGELOG.md/docs — no user-visible behaviour change.
• Nothing private is being committed.

How it was verified

bun run lint, bun run typecheck, bun run build && bun test tests/node/local-ai.test.ts (69 pass, including the existing file-lock recovery test "old ownerless locks recover..."), bun run test:unit (1271 pass, 2 pre-existing failures noted above).

Link to Devin session: https://app.devin.ai/sessions/569c32d5684e44a9842340dc0a327a4b
Open in Devin Desktop: https://app.devin.ai/desktop/session/569c32d5684e44a9842340dc0a327a4b?variant=devin
Requested by: @CuriosityOS

[devin-ai-integration]

I'll fix CI failures and address comments from users with write access. I'll skip comments containing "(aside)".

• Disable automatic comment, CI, and merge conflict monitoring

[devin-ai-integration]

Starting E2E review of BetterWright/betterwright PR #220 (head 1e4ac41).

[greptile-apps]

Confidence Score: 4/5

This PR is not safe to merge until stale regular-file reclaim can no longer move a concurrently published live directory lock.

Summary

This PR removes the special stale regular-file reclaim branch from withLocalLock and routes those entries through the directory-oriented tombstone reclaim flow.

• Ordinary stale-file recovery still completes.
• The new path can relocate a concurrently published live directory lock, breaking mutual exclusion.
• Reclaimed files now leave persistent fingerprinted tombstones.

Diagram

sequenceDiagram
  participant A as Contender A
  participant L as Lock path
  participant B as Contender B
  A->>L: Observe stale regular file
  B->>L: Reclaim stale file
  B->>L: Publish fresh directory lock
  A->>L: Rename current path to stale tombstone
  Note over A,L: B's live lock is moved away
  A->>L: Publish its directory lock
  par Concurrent protected work
    A->>A: Run work()
    B->>B: Run work()
  end

Loading

_{Reviews (1) · Last reviewed commit: "Remove obsolete legacy file-lock reclaim..."}

[greptile-apps]

Comments Outside Diff

These findings sit on lines the diff does not cover, so they could not be posted inline. Each one leaves this list once its file changes.

•  Live lock can move src/local-ai-install.ts:127 ▶

  When two contenders race over a stale regular-file lock, one contender can publish a fresh directory lock after the other has inspected the stale file but before it calls renameSync. The rename then moves the fresh lock to the tombstone without confirming its identity. The first contender can acquire the newly vacant path, allowing both contenders to run work() concurrently. The deleted unlinkSync path avoided this because unlinking a directory failed and caused a retry instead of moving the active lock.

•  Stale tombstones accumulate src/local-ai-install.ts:127 ▶

  A reclaimed regular-file lock is now renamed to a fingerprinted .stale-* path, but withLocalLock only cleans up the active lock or unpublished candidate. Each stale-file recovery can therefore leave another permanent tombstone with a distinct inode-derived name, causing unnecessary files to accumulate over time.

[CuriosityOS]

Landed on main via #224 (consolidated dead-code cleanup).