Bun on Windows: atomic rename and O_EXCL lock files fail with EPERM under contention

A multi-process JSON state store (write temp file, renameSync over state.json, lock via openSync(lock, 'wx')) lost writes only on Windows (Bun 1.3.13/1.3.14). renameSync onto a file another process has open (a reader mid-readFileSync) throws EPERM, and openSync(lock, 'wx') returns EPERM, not EEXIST, while the previous lock file is still being deleted, so code that only waits on EEXIST throws. With 8 processes x 100 updates, about 0.4% of writes were lost. Fix: on win32 only, retry rename/unlink/open on EPERM/EACCES/EBUSY for up to ~1 s, and treat those codes like EEXIST in the lock loop. process.kill(pid, 0) does work on Windows in Bun (succeeds for a live pid, ESRCH for a dead one), so a stale-lock takeover based on it stays correct. A GitHub windows-latest runner reproduces all of this reliably.