Disallow events in FutexEmulation, but order Wait calls - #170

Port of the Chromium V8 fork's "[RUN-2378] Disallow events in FutexEmulation, but order Wait calls" (replayio/chromium-v8 nodejs#199), as the file stands there today. The futex emulation's own synchronization (its global mutex, the per-node condition variables and the wait list) now runs with events disallowed in NotifyWake, AtomicsWaitWakeHandle::Wake, WaitSync, WaitAsync, Wake, ResolveAsyncWaiterPromises, HandleAsyncWaiterTimeout, IsolateDeinit and the *ForTesting counters, so none of it is recorded. The public Wait entry point instead asserts on entry and exit through the new recordreplay::AutoAssertMaybeEventsDisallowed scope, which records the order of Wait calls.

Until now the wait was recorded through its condition variable. A recording of a worker blocking in Atomics.wait while the main thread notifies it could not be replayed: every replay crashed with an assert mismatch on the worker thread.

Differences from the Chromium change

• The scopes use node's existing v8::replayio::AutoDisallowEvents (Chromium renamed to it in [TT-819] Fix Asserts in RejectPromise chromium-v8#226).
• AutoAssertMaybeEventsDisallowed is declared next to AssertMaybeEventsDisallowed, formats with vsnprintf and asserts through that existing function, which does the same checks.
• Tasks are not posted while events are disallowed. Node's platform posts through a task queue mutex and uv_async_send, which are the events that order the receiving thread after the post, and asserts in PostTask. Wake collects the tasks resolving other isolates' async waiter promises and posts them after releasing the lock and ending the scope. With the posting inside the scope, a worker's Atomics.waitAsync woken by the main thread replayed with an empty task queue and diverged. WaitAsync posts its timeout task the same way; inside the scope it only left warnings, since it posts to the waiter's own isolate.
• A post from another thread could already race the waiter isolate's PerIsolatePlatformData::Shutdown: node unregisters an isolate from the platform before disposing it, and nothing synchronized the flush handle. Posting after releasing the futex lock widens that window, so the platform now guards the handle with an ordered mutex (it nests the task queue's and the async handle's ordered locks) and discards a task posted during or after Shutdown.

Testing

Backend case test/node-recording/tests/worker-threads/atomics-wait-notify (branch claude/node-recording-gc-tests): a worker blocks in Atomics.wait with and without a timeout on cells the main thread notifies after a timer, other waits time out or find a changed value, and the same outcomes go through Atomics.waitAsync in the worker and in the main thread; the replay must report the same outcomes and woken counts.

• On master: records fine, replay crashes with an assert mismatch on the worker thread, 4 of 4 runs.
• With the Chromium scopes alone: the worker-side waitAsync woken by the main thread still crashed the replay (bisected with program variants); sync waits and the main-thread waitAsync passed.
• With this change: 5 of 5 runs pass, plus 3 runs after each review round. tests/worker-threads passes; tests/gc has the same 11 failures as master (they need the old-space-GC stack).

Not covered by the test: AtomicsWaitWakeHandle::Wake and the *ForTesting paths.