fix(libnpmexec): fix lock compromise logic

[jenseng]

Fix a race condition in withLock where a slow fs.stat call could result in an ECOMPROMISED false positive. Due to the usage of setInterval, one callback could mutate mtime just before an overlapping callback's fs.stat promise has resolved, causing a mismatch. By switching to setTimeout, we ensure that we don't have overlapping callbacks and incorrect values.

Additionally bump the stale threshold higher, to reduce the likelihood of another caller taking over a seemingly-stale-but-actually-active lock. Under Windows in particular, fs.stat has been observed to sometimes take over 20 seconds, so we should err on the side of a higher threshold before we judge a lock as stale. The minor potential downside is that we might wait longer before taking over a stale lock, but lock takeover is already a very exceptional case (i.e. it would typically only happen if another process was SIGKILLed while holding the same lock)

Testing Notes

• Added a new test to cover this scenario
• Verified the failure and the fix via one-off GHA workflow that does npx --yes jest --version

References

Fixes #8710

[jenseng]

Under Windows in particular, fs.stat has been observed to sometimes take over 20 seconds

I suspect this may not be due to any underlying bugs in fs.stat or anything like that. Rather it seems likely that in certain cases (e.g. installing a very large package like jest in a Window VM) that arborist can block the event loop for multiple seconds.