Fix Process.waitall/detach under URing selector when no children remain

[samuel-williams-shopify]

Summary

Fixes Process.waitall / Process.detach under the URing selector when there are no more children to reap.

The bug

The URing selector's process_wait hook (the io_uring waitid path) raised via rb_syserr_fail when waitid reported an error such as ECHILD:

if (result < 0) {
    rb_syserr_fail(-result, "...:io_uring_prep_waitid");
}

But Process.waitall (and Process.detach) rely on rb_waitpid returning -1 with errno == ECHILD so they can terminate their loops — they do not expect it to raise (see proc_waitall in Ruby's process.c). Under a fiber scheduler this path goes through the hook, so raising broke them: Process.waitall would propagate Errno::ECHILD instead of returning the statuses it had already collected.

Process.wait(-1) with no children still raises Errno::ECHILD — that's correct and unchanged (it matches non-scheduler behaviour).

The threaded fallback (EPoll / KQueue / Select) was already correct, because it reaps via Process::Status.wait, which returns the proper (-1, errno) carrier rather than raising.

The fix

Route waitid errors through the same WNOHANG reap already used on the success path. rb_process_status_wait(pid, flags | WNOHANG) reproduces the failure as a Process::Status carrying (pid -1, errno), exactly like Process::Status.wait — so rb_waitpid reports it correctly and waitall/detach behave as expected. No new API required.

Tests

Adds integration tests (via TestScheduler, across all selectors):

• Process.waitall collects all child statuses and terminates cleanly.
• Process.wait(-1) with no children raises Errno::ECHILD (regression guard for the corrected behaviour).

Verification

• Reproduced first: the new waitall test errors with Errno::ECHILD only on the URing waitid path (EPoll/Select pass).
• With the fix: green on Linux (EPoll + URing-waitid + Select) — 150/150 — and macOS (KQueue + Select) — 112/112.

Background

This came out of the discussion on bug #21704 about exposing rb_process_status_new. Notably this fix needs no new Ruby API — rb_process_status_wait already provides the full-fidelity reap (including the error carrier). A constructor like rb_process_status_new would only be needed later to avoid the extra reap syscall on the success path.