On Windows, the device lock fails while another run deletes a lock file #218

Describe the bug

Windows reports a file that another process is deleting as EPERM rather than ENOENT until the deletion completes: reading a file in a create/delete loop on Windows 11 gave 160 EPERM among 7,126 reads. The device lock (packages/jest/src/resource-lock.ts) reads its owner and queue files while other runs delete them, and treats only ENOENT as absent, so:

• a run waiting for a device can fail with EPERM: operation not permitted, open '…\owner.json' when the holder releases it;
• the heartbeat's read of owner.json sits outside the catch that makes a failed refresh harmless, and rejects unhandled. Under load, resource-lock.test.ts reports it three times:

Unhandled Rejection
Error: EPERM: operation not permitted, open '…\react-native-harness-resource-lock-test-…\owner.json'

Separately, on every platform release does not wait for a heartbeat refresh in progress. A refresh that has passed its check writes owner.json back after release removed it, so the next run in the process waits for the lock to go stale.

I have a fix for the three. I can open a PR.

System Info

System:
  OS: Windows 11 10.0.26200
Binaries:
  Node: 26.8.1

React Native Harness Version

1.6.0 (main at bca0781)

Reproduction

https://github.com/callstackincubator/react-native-harness/blob/main/packages/jest/src/__tests__/resource-lock.test.ts

Steps to reproduce

1. On Windows, run pnpm nx run-many -t test so the Jest package's tests run beside others.
2. vitest reports the unhandled EPERM from resource-lock.test.ts.