Use socket pairs for remaining scheduler control fds on Windows (fixes #5245)

[cdgraff]

Fixes #5245.

Root cause

The leak is Windows-only because it lives in OCaml's Unix.select emulation, not in output.harbor itself. On Unix, duppy uses the poll() C stub, which is why the leak never reproduced on mac/linux.

OCaml's select_win32.c has two paths:

• A plain winsock select() fast path, taken only when every fd in the call is a socket ("only sockets to select on, using classic select").
• Otherwise, a worker-thread emulation (winworker.c + WSAEventSelect + per-call event handles) that leaks native memory on every call — invisible to the OCaml GC, which matches the flat process_managed_memory in the issue logs.

Two pipes were permanently registered in the Tutils scheduler, so every scheduler iteration took the leaking path:

1. harbor.ml — the accept-loop control fd (Unix.pipe)
2. duppy.ml — the Duppy.Monad.Mutex.Factory wake pipe, created unconditionally when server.ml loads

This also explains the observed behavior across versions: leak rate scales with scheduler wake rate. On 2.4.5 the scheduler only churns while listeners are connected (~45 MB/min with one client, stable without). On main, the rewritten harbor output wakes the write task every frame, so memory grows even with no listeners, and faster (~280 MB/min).

Fix

Convert both remaining pipes to Unix_utils.socketpair, following the same conversion already done for the scheduler wake fd, Duppy.Async, and the harbor output write task. With sockets only in the set, Windows select always takes the leak-free fast path.

Notes

• process_handler pipes still enter the scheduler while an external process runs, so scripts using process.run on Windows would temporarily re-enter the emulation path. Left out of scope here.
• Independent upstream issue worth reporting to ocaml/ocaml: in socket_poll (select_win32.c), any mid-setup error skips the entire cleanup loop, leaking all CreateEvent handles and leaving WSAEventSelect associations on the sockets.

Validation

We can reproduce the leak reliably on Windows 11 (25+ machines, physical and virtual). Once CI produces the Windows artifact for this branch we'll run the reproduction script from #5245 and report memory behavior with and without connected listeners.

[toots]

Great find thanks! I have confirmed and reported the issue with the OCaml maintainers: ocaml/ocaml#14975