socket_ipc: remove the 100 ms poll timeout from the macOS connect handshake

Bắt đầu với Client::connect trong crates/socket_ipc/src/unix.rs và đọc handshake macOS hiện có cùng mã công bố server-pid. Điều tra hành vi của kqueue EVFILT_READ và EVFILT_PROC NOTE_EXIT được mô tả trong issue, đồng thời giữ nguyên đường dẫn POLLERR hiện có của Linux. Hoàn thành khi thao tác chờ trên macOS không còn timeout 100 ms hoặc probe mở lại, và kết thúc khi nhận được ready byte hoặc khi server thoát.

Problem

While a client waits for the server's ready byte, it polls with a 100 ms timeout and reopens the connect FIFO on every tick to check that the server is alive.

The timeout is there because macOS does not report FIFO peer death. On Linux, POLLERR fires at once on the rendezvous write end. On macOS nothing fires, so an untimed wait would hang forever when the server dies mid-handshake.

Code: Client::connect in crates/socket_ipc/src/unix.rs (added in #569).

Measurements

macOS 27, run bare and inside both the Codex CLI and Claude Code sandboxes:

No FIFO event reports a dead peer on macOS. Watching the process is the only mechanism that works.

Also measured, in both sandboxes:

• EVFILT_READ delivers the ready byte reliably when the read end is opened before any writer exists, which is the handshake order.
• Registering NOTE_EXIT on a pid that already exited returns ESRCH, so "server already gone" needs no extra race handling.
• Watching an unrelated same-user pid is allowed, so the client can watch the runner.

Proposal

Register EVFILT_READ on the response FIFO and EVFILT_PROC NOTE_EXIT on the server pid in one kqueue, then block in a single kevent with no timeout. The wait ends when the ready byte arrives or the server exits. The 100 ms tick and the reopen probe both go away.

The server publishes its pid next to the connection name.

Cost

• The connection name has to carry the server pid.
• A pid reuse window appears. If the server exits and the same pid is reused during the handshake, the watch follows the wrong process. Darwin cycles through the pid space before reuse, so this is remote, while the current probe asks the kernel about the exact FIFO and has no such window.
• macOS only. Linux keeps POLLERR and already needs no timeout.

Priority

Low. The happy path already wakes immediately, so the timeout only adds latency when the server dies during the handshake, which is rare.