Propagate file-lock compromise and release errors #1850

Summary

Follow up on the lock-compromise and release-error paths identified in PR #1726. proper-lockfile@4.1.2 can call onCompromised from an asynchronous renewal timer after acquisition. Throwing in that callback can cause an uncaught exception instead of failing the owning operation. The current release paths can suppress errors after an otherwise successful operation.

Required changes

• In src/utils/fileLock.ts, record lock compromise without throwing from onCompromised. Make the release wrapper propagate a recorded compromise, even if the underlying release resolves.
• In src/utils/fileLock.ts (withFileLock) and src/utils/safeWriteJson.ts, propagate release errors when the operation otherwise succeeds. If the operation already failed, preserve the primary error.
• Add focused tests for the asynchronous compromise callback, a release error after success, and a release error after an operation failure.

Acceptance criteria

• Lock compromise does not throw uncaught from the renewal timer and is reported by the owning operation through its release path.
• A successful operation does not report success when release fails.
• An operation failure remains the primary error when release also fails.
• Tests cover these paths for the affected helpers.

Context

• PR: Stop interrupted tasks from replaying rejected subtasks #1726
• Review thread: Stop interrupted tasks from replaying rejected subtasks #1726 (comment)
• Requested by: @edelauna