fix(task-runner-native): settle wait() for a process that already closed

[ddeboer]

NativeTaskRunner.wait() could hang forever, in three different ways. All of them need a caller that does not wait for one task before starting the next – which is exactly what the worker pool in #782 (must 1) will do, and why this lands first.

The hangs

1. Waiting for a process that already closed. wait() attached its close listener only when it was called, so a process that had already closed left it waiting for an event that would never fire again. The promise never settled: no error, no timeout. Sequential code hides this; a pool does not, and a task that fails fast – a bad jar path exits in milliseconds – closes in between. stop() already guarded for an exited process; wait() did not.
2. Stranding a stop() in flight, or a concurrent wait(). wait() called removeAllListeners('close'), which strips every listener, not just the one run() installed. A stop() in flight lost its cleanup listener, so it never resolved and its SIGKILL timer was never cleared; a second, concurrent wait() deleted the first waiter's listener, so the first promise never settled.
3. Waiting twice. Reading a task's output consumed it, so a second wait() answered with an empty string.

The fix

The class kept a task's state in four places – two Maps keyed by pid, two WeakMaps keyed by the process – and read the output destructively. That is what made each of the above a separate case to handle.

It now keeps one record per task, created the moment the process exists: its output, and a promise that resolves when it closes. wait() and stop() read that record and nothing else.

The three hangs stop being cases to handle at all:

• awaiting a promise that already resolved is ordinary, so a closed process needs no lookaside;
• a promise settles every waiter, so concurrent waits need no shared record;
• reading a field is not destructive, so waiting twice answers the same thing;
• no listener is ever removed, so a stop() in flight keeps its own.

Net -79 lines in the class.

Two defects that were going to need a follow-up PR are gone with it: state is keyed by the process rather than by pid – which the OS recycles, so a long-lived runner could serve one task's output to another – and held weakly, so output is released with the process object instead of accumulating for the runner's lifetime (ADR 12).

One behaviour removed

run() emitted a synthetic 'error' event on a non-zero exit, which the no-op listener installed two lines below absorbed – observable to nobody. A genuine spawn failure still arrives as a real 'error', still has a listener so Node does not throw it, and still reaches the caller through wait().

Tests

Six new cases, four of which timed out rather than failed before the fix – that is what a hang looks like in a suite, and why this went unnoticed: a process that already succeeded; one that already failed; one already stopped; a stop() in flight alongside a wait(); two concurrent waiters; and waiting twice. They were written against the previous, more elaborate fix and pass unchanged against this one.