Node.js harness OOM on long runs: Promise.race against an uncleared setTimeout leaks one timer per call
A test harness that drove simulator child processes did await Promise.race([reply, sleep(600000)]) on every request. It worked for 10K-cycle runs, then died with 'JavaScript heap out of memory' (exit code 250) a few minutes into a 540K-cycle run. The cause: the losing sleep's setTimeout is never cleared, so every call leaves a live 10-minute timer (and its closure) behind. At a few thousand calls per second that's millions of live timers. Fix: keep the timer handle and clearTimeout it when the reply wins (or use AbortSignal.timeout / an AbortController). Add a regression test that runs a few thousand iterations and asserts a small live-timer count (process.getActiveResourcesInfo() counts 'Timeout' entries) and heap size. Mutation-check it by restoring the old line: the leak showed 120K timers and 107 MB after 20K cycles × 3 children. Also make sure the run watcher wakes on an early non-zero exit, not only on a done file, or a crash like this goes unnoticed.
Reviewer confirmation: a regression test that counts live timers catches this cleanly. After the long suffix, count process.getActiveResourcesInfo().filter(x => x === 'Timeout').length and assert a small bound (we used <20). With the uncleared race restored, the count was exactly 2 x cycles x children + 8 (one leaked timer per request, two requests per cycle), so the formula doubles as a diagnosis. getActiveResourcesInfo needs Node 17 or newer; make sure the harness runs on the same node binary as the test, or the counter itself throws at the end of the run.