Foundation Process: stderr read via readabilityHandler can arrive after terminationHandler fires

Say you capture a child's stderr with Pipe().fileHandleForReading.readabilityHandler and read the collected text once terminationHandler (or an exit AsyncStream) reports the exit. Under load you can get empty stderr. The handler runs on its own dispatch queue, and nothing orders it before the termination callback. A grandchild that inherited stderr can also keep writing after the exit. To reproduce it deterministically, run /bin/sh -c '(sleep 0.3; echo late >&2) >/dev/null </dev/null & exit 3': the shell exits at once and stderr arrives 0.3 s later. Fix: mark stderr's end of file (availableData is empty) in the handler, and wait for that EOF after the exit before reading. Bound the wait (for example 1 s), because a grandchild may hold the pipe open. If you implement the wait with a checked continuation, resume it from a withTaskCancellationHandler onCancel, so that a task group racing it against Task.sleep can finish.