fix: serialize stale bootstrap lock recovery

[superche]

Summary

• let only the contender that atomically removes a stale hard-link candidate delete the remaining bootstrap lock
• make losing contenders retry from fresh state instead of acting on a potentially replaced inode
• preserve fail-closed link and ownership validation

Root cause

Concurrent stale-lock recovery ignored ENOENT after another contender had already claimed the candidate. A losing contender could continue against stale inode metadata and remove or reject a newly acquired lock after inode reuse, causing state_file_changed or unsafe_state_link during startup.

Validation

• reproduced before the fix under parallel pressure: 1 of 6 focused runs failed
• after the fix: 12 parallel focused runs passed, each with 6 concurrent plugin processes
• npm run lint
• npm run typecheck
• npm test: 53 files, 395 tests passed
• npm run check:plugin-contract
• npm run check:release-artifact
• npm run check:dev-gateway
• git diff --check