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

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.

Beginnen Sie mit Client::connect in crates/socket_ipc/src/unix.rs und lesen Sie den vorhandenen macOS-Handshake sowie den Code zur Veröffentlichung der Server-PID. Untersuchen Sie das im Issue beschriebene Verhalten von kqueue EVFILT_READ und EVFILT_PROC NOTE_EXIT, wobei der bestehende POLLERR-Pfad von Linux erhalten bleiben muss. Als erledigt gilt die Aufgabe, wenn das Warten unter macOS kein 100-ms-Timeout oder keinen Reopen-Test mehr enthält und bei entweder dem Ready-Byte oder dem Beenden des Servers endet.