Prevent split locks across safeWriteJson symlink replacement #2374

Summary

safeWriteJson can use different advisory lock keys for writers that publish to the same caller-named path when a symlink is replaced. A writer can resolve the symlink to its referent before waiting for the lock. After another writer replaces the symlink entry, a later writer can lock the named path instead. Both writers can then enter recovery or merge concurrently for the same publication path.

Concurrent recovery can remove another writer's active staged file. Concurrent read-merge-write operations can also lose an update.

Affected areas

• src/utils/safeWriteJson.ts: lock-key selection, recovery, merge, and named-path publication.
• src/utils/fileLock.ts and src/utils/jsonFileRecovery.ts: shared lock and recovery behavior.
• src/utils/__tests__/safeWriteJson.test.ts: lock and publication regression coverage.

Required work

A maintainer should choose a lock-key contract that keeps publication and recovery serialized across symlink replacement, while preserving the intended alias and symlink-refusal behavior. Coordinate all participants that access the same publication path, including recovery and deletion. Avoid deadlocks if the chosen contract uses multiple locks.

Acceptance criteria

• Add a deterministic concurrent regression test with writers that resolve the same named path before and after its symlink is replaced. Verify that merges do not lose updates and recovery does not delete an active staged file.
• Test the chosen contract for an alias and its referent, and for interactions between default and refuseSymlinkTarget writes.
• Preserve caller-named publication and the existing symlink-refusal contract. Test lock release and error paths as appropriate for the chosen design.
• Document the maintainer's contract decision and any necessary coordination with recovery and deletion.

Context

Requested by @easonLiangWorldedtech as a separate follow-up, not an amendment to #2350.

PR: #1405
Review thread: #1405 (comment)