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.

Start with Client::connect in crates/socket_ipc/src/unix.rs and read the existing macOS handshake and server-pid publication code. Investigate the kqueue EVFILT_READ and EVFILT_PROC NOTE_EXIT behavior described in the issue, while preserving Linux's existing POLLERR path. Done means the macOS wait has no 100 ms timeout or reopen probe and ends on either the ready byte or server exit.