Using `ScheduledExecutorService` for timeouts

Currently, the timeout operation is implemented by racing given operation with a sleeping thread (BTW a similar approach is used in Cats Effect).
I was wondering if we could leverage a ScheduledExecutorService instead. It operates on a single threaded, which schedules and starts actual tasks. Netty uses this mechanism for timeouts in its IdleStateHandler. A scheduled task starts, emits an event and ends immediately. Then, Netty's internals handle the event in order to abort communication if a timeout occured.

In case of Ox, a scheduled task would start on a virtual thread (see hints in this Stack Overflow discussion). It would then call cancelation of the fork that's wrapped with timeout.

I don't know if such a solution will be more performant than racing with a sleeping thread, but I'm leaving this idea here for consideration. One certain issue is that the single-threaded pool for scheduling doesn't sound like something we want to create for each scope, but rather like a "runtime" that needs passing around.

Start by locating the timeout operation and the runtime or scope lifecycle that would own scheduling. Compare the current sleeping-thread race with ScheduledExecutorService and the linked Netty IdleStateHandler approach; the issue does not define acceptance criteria for performance, cancellation, or runtime ownership.