The three ASIO backends must each yield to the systematic-testing scheduler the same way

Under use=systematic_testing the ASIO event-loop thread is one of the cooperatively-scheduled threads, so when it gets its turn it must promptly hand control back rather than block on I/O — otherwise, because only one thread runs at a time, the whole interleaving stalls (no actor ever runs, and shutdown coordination — which must wake the ASIO thread so it observes the stop request and exits — never completes). Each backend's wait loop therefore needs two things in step: (1) a bounded wait timeout instead of an infinite one (epoll.c wait_time = 10ms vs -1; kqueue.c ts.tv_nsec = 10000000 vs a NULL timeout; sock_notify.c wait_ms = 10 vs INFINITE), and (2) a SYSTEMATIC_TESTING_YIELD() on the reachable path right after the wait returns. Both are no-ops in non-systematic builds (SYSTEMATIC_TESTING_YIELD() expands to nothing and the timeout stays infinite). The backends are platform-exclusive — epoll.c (Linux), kqueue.c (BSD/macOS), sock_notify.c (Windows) — and each is only compiled and run on its own platform, so a change to the yield pattern in one is invisible to the others. Nothing in normal CI builds systematic_testing at all; the Linux pattern is guarded only by the weekly determinism_smoke.py (see systematic-testing-send-ordering.md), and the Windows (sock_notify.c) pattern has no CI coverage yet — a regression there surfaces only when someone builds use=systematic_testing on a Windows host by hand. The sock_notify.c trap is placing the SYSTEMATIC_TESTING_YIELD() after the if(!ok) continue; that follows GetQueuedCompletionStatusEx rather than before it: under the finite wait a WAIT_TIMEOUT takes that continue, so a yield below it would never run and the asio thread would spin without handing control back. Run on each platform's host: build use=systematic_testing and confirm a trivial actor program reaches the "Systematic testing successfully finished!" banner.