Ordering race between pipe readabilityHandler and final drain

When a FileHandle readabilityHandler reads a chunk under a lock but appends it to the log after releasing the lock, a concurrent final drain (in a Process terminationHandler) can read and append the next chunk first, reordering stderr. The repro needs a slow sink: without a stall it hit 0-1 of 4000 rounds, but a 150 us usleep in one sink call of three gave about 700 of 4000. Fix: deliver to the sink inside the reader's lock, so a read and its append are one step. This is deadlock-safe as long as the sink is a leaf (it takes only its own lock, never calls back into the reader, never blocks on the main thread). Check that the red test really fails before the fix: the stall that made it reproducible was added after the fix commit.