The hunk increases `tests.discovered.total` from 52 to 57, but the surrounding context shows the same item list as before (no new test entries added in this hunk). If the items array was not also extended to 57 entries, this fixture update violates the guardrail that fixture updates must map to intentional, consistent behavior changes and that JSON fixtures preserve stable structured output envelopes. This risks the fixture being updated only to make tests pass rather than reflecting a real behavior change.

Starting April 2026, the CodeQL Action will skip computing file coverage information on pull requests to improve analysis performance. File coverage information will still be computed on non-PR analyses. To opt out of this change, create a custom repository property with the name `github-codeql-file-coverage-on-prs` and the type "True/false", then set this property to `true` in the repository's settings.

In shouldRecoverLockDir, when readLockOwner returns null and the directory is older than the lease (lines 85-88), tryRecoverExpiredLockDir proceeds to quarantine and unconditionally remove the lock dir without re-validating after the rename. Between the readLockOwner/isDirectoryOlderThan checks and the fs.rename in quarantineLockDir, another process can legitimately create owner.json inside that directory (e.g., createLock racing on the same path). Because the recovery.owner === null branch skips the fsLockOwnersEqual post-rename verification used in the non-null branch (lines 116-122), the racing process's valid lock is silently destroyed at line 124, leading to lost-lock and potential double-acquisition by two processes that each believe they own the lock.

In shouldRecoverLockDir, when readLockOwner returns null and the directory is older than the lease (lines 85-88), tryRecoverExpiredLockDir proceeds to quarantine and unconditionally remove the lock dir without re-validating after the rename. Between the readLockOwner/isDirectoryOlderThan checks and the fs.rename in quarantineLockDir, another process can legitimately create owner.json inside that directory (e.g., createLock racing on the same path). Because the recovery.owner === null branch skips the fsLockOwnersEqual post-rename verification used in the non-null branch (lines 116-122), the racing process's valid lock is silently destroyed at line 124, leading to lost-lock and potential double-acquisition by two processes that each believe they own the lock.

scheduleWorkspaceFilesystemLifecycleSweep adds scheduleKey to runningScheduledSweeps and sets a timer, but if the timer's sweep returns skippedByCooldown or skippedByLock, lastScheduledAtByScope/lastScheduledAtByPreKey are NOT updated. Subsequent calls will pass the cooldown gate (since lastAt remains stale/undefined) and re-schedule repeatedly. Combined with the unref'd timer, this can cause busy rescheduling under contention without progress, and the pre-key cooldown protection is bypassed.