Fix flaky timing test in lock.spec.ts

[TaprootFreak]

Summary

• Replace timing-based test with Promise-based synchronization
• The original test used setTimeout without delay causing race conditions
• New test uses explicit Promise signaling for deterministic behavior - no timing dependencies

Changes

The old test relied on timing (Util.delay(10) vs Util.delay(1)) which could fail under CI load.
The new test uses Promise-based coordination:

1. First lock signals when acquired via lockHeld Promise
2. Test waits for signal before attempting second lock
3. First lock waits for releaseFirstLock() before completing

Test plan

• Test passes consistently (verified 10/10 runs locally)
• All other tests still pass (48 passed, 1 skipped)
• No timing dependencies - fully deterministic