fix(pty): preserve concurrent fast-exit output

[privatenumber]

Problem

On Unix, a fast child could exit before JavaScript drained the PTY master, allowing pty.exited to resolve before pending output callbacks. A Node 24.15.0 macOS arm64 reproduction lost FAST in 52/100 concurrent onData runs and 55/100 concurrent terminal.data runs; sequential runs lost none.

Moving reads native also requires explicit ownership across pause, close, Worker teardown, raw callbacks, and process trees. Without coordinated ownership, queued callbacks can outlive close, recycled fd/PID values can target unrelated resources, and descendants can retain the PTY after their leader exits.

Changes

Unix now starts the child suspended, starts a native reader, and then resumes the child. Data and exit share one bounded Node-API queue, so exit cannot overtake output delivery. Pause applies bounded native backpressure; close suppresses queued callbacks and forces deterministic cleanup even when SIGHUP is ignored.

JavaScript owns the returned fd while native reading uses a CLOEXEC duplicate. Worker cleanup closes the public fd only when its identity still matches the original PTY, preventing recycled-fd double-close. The exit monitor observes leader exit with waitid(..., WNOWAIT), keeping a non-recyclable process-group anchor until same-group descendants and the reader are cleaned; intentionally detached descendants remain caller-owned.

Regressions cover 100 concurrent fast exits, Darwin pause/resume, callback reentrancy, ignored-SIGHUP and Worker disposal, fd close/reuse, leader-first process groups, real fault injection, and repeated thread/fd cleanup. Fixed direct reproductions lose 0/100 outputs through both callback APIs.