fix: treat null signal as no cancellation under contention

[cursor]

Bug and impact

Under contention, lock(null) / withLock(fn, null) rejected with TypeError after enqueueing a waiter. That zombie then made the holder's release() throw on null.removeEventListener, so:

1. Successful withLock work was reported as failed (throw in finally)
2. Later acquirers could jump ahead of live FIFO waiters while isLocked() briefly looked free

Root cause

The abortable path used signal !== undefined, so null entered abort setup. addEventListener threw after enqueue, leaving a waiter whose patched acquire() also assumed a real signal.

Fix

• Treat null like "no signal" (signal != null)
• If subscribe throws for a non-signal value, unlink the waiter before rethrowing

Validation

• Added regression tests for null under contention, withLock holder release, and non-signal cleanup
• npm test: 20/20 passed at 100% coverage

  

---

Note

Low Risk
Small, targeted change to optional AbortSignal handling in the lock implementation, with new regression tests and no API surface change.

Overview
Fixes a contention bug where lock(null) / withLock(fn, null) incorrectly entered abort handling (signal !== undefined), which could enqueue a broken waiter, throw on addEventListener, and later break the holder’s release() (FIFO and error reporting).

create.js now treats null like “no signal” via signal != null for abort wiring, and rejects non-AbortSignal values up front with TypeError before queueing or taking a slot.

Regression coverage in test/cancel.js for null under contention, withLock holder release, and invalid signal arguments.

^{Reviewed by Cursor Bugbot for commit 004bbae. Bugbot is set up for automated code reviews on this repo. Configure here.}