Async proactor fixes: TSAN bridge and progress callback starvation

[benvanik]

Two fixes for the async proactor infrastructure, both motivated by SHM carrier integration work.

TSAN bridge for kernel-mediated completion ordering

Proactor backends that use kernel-managed shared memory rings (io_uring SQ/CQ, IOCP completion ports) have an ordering gap invisible to TSAN: the submitter thread writes operation fields, the kernel processes the I/O, and the poll thread reads those fields from a completion event — but TSAN sees no userspace synchronization between the write and the read.

This adds a C11 atomic bridge (iree_async_operation_t::tsan_bridge) that makes the kernel-provided ordering visible. The submitter stores with release ordering after filling the operation; the completer loads with acquire ordering before reading operation fields. The field and both macros compile to nothing outside IREE_SANITIZER_THREAD builds.

Supporting changes:

• iree_async_operation_zero(): Replaces raw memset for operation struct reuse. C11 forbids mixing atomic and non-atomic accesses to the same object; memset over atomic fields is a non-atomic write that TSAN correctly flags. The new helper zeroes only the subtype-specific tail, leaving the base struct's atomic fields to be set properly by iree_async_operation_initialize().

• software_op_mask bitmap in io_uring submit: After Phase 2 submits kernel SQEs, another thread's flush can make them visible to the kernel. A fast-completing kernel op (NOP, expired timer) could have its operation struct reused before Phase 3 iterates past it. Previously Phase 3 re-read operation->type to decide whether to skip kernel ops — a data race with the new owner's writes. Now Phase 1 records which batch positions are software ops in a bitmap, and Phase 3 uses the bitmap instead of re-reading types.

• CTS stress tests: Three test cases exercise the bridge under TSAN — single-thread rapid reuse (200 cycles), multi-thread contention (4 threads, 8-slot pool), and high-frequency reuse (2 threads, 2-slot pool forcing maximum reuse rate).

Progress callback starvation fix

All three proactor backends (io_uring, IOCP, POSIX) previously only forced non-blocking poll when progress callbacks returned > 0 completions. A newly registered callback that hadn't yet observed progress would not prevent the proactor from blocking in its platform wait (io_uring_enter, GetQueuedCompletionStatusEx, event_set_wait), starving the callback until an unrelated I/O event broke the wait.

Fix: force non-blocking poll whenever any progress callback is registered (progress_list != NULL), not just when one returns progress. The carrier's idle spin threshold naturally removes the callback when the ring goes quiet, bounding the busy-loop duration.

The POSIX backend also adds a pending queue drain after progress callbacks, ensuring that operations submitted by callbacks (e.g., notification re-posts) are registered with the event set before the blocking wait. Without this, their fds wouldn't be monitored and the poll would miss wakeups.

Notification signal_primitive

Adds a signal_primitive field to the io_uring notification struct, separate from the polled primitive. For local notifications both are the same eventfd. For shared/proxy notifications (SHM carrier peer wake), signal_primitive is the peer's eventfd while primitive may be NONE (not polled locally). This enables asymmetric notification patterns where the signaling end differs from the monitoring end.