Fix GC safety of blocking_operation in rb_fiber_scheduler_blocking_operation_wait

rb_funcall(scheduler, :blocking_operation_wait, 1, blocking_operation) can
cause a fiber switch if the scheduler calls rb_fiber_scheduler_block. When
the fiber is suspended, the C frame of rb_fiber_scheduler_blocking_operation_wait
is no longer active. In optimised builds (-O3 --enable-shared), blocking_operation
may be held only in a machine register not saved/scanned by the conservative GC,
allowing it to be collected. get_blocking_operation() at line 1104 then reads
freed/reused memory, crashing with rb_unexpected_object_type.

Confirmed by reproducing the crash using:
  ./configure --enable-shared --disable-install-doc --enable-yjit cppflags=-DENABLE_PATH_CHECK=0

RB_GC_GUARD(blocking_operation) after rb_funcall forces the compiler to keep
the VALUE on the stack (volatile read), ensuring the GC always finds it.

See: socketry/io-event#170
     socketry/io-event#171
Co-authored-by: Cursor <cursoragent@cursor.com>

Author: samuel-williams-shopify

scheduler.c

@@ -1100,6 +1100,13 @@ VALUE rb_fiber_scheduler_blocking_operation_wait(VALUE scheduler, void* (*functi
 
     VALUE result = rb_funcall(scheduler, id_blocking_operation_wait, 1, blocking_operation);
 
+    // If the scheduler causes a fiber switch during the call above (e.g. via
+    // rb_fiber_scheduler_block in a worker-pool), the calling fiber's C frame
+    // is suspended. With optimised builds, `blocking_operation` may only be in
+    // a machine register not scanned by the conservative GC, allowing collection.
+    // RB_GC_GUARD forces it onto the stack so it is always reachable as a root.
+    RB_GC_GUARD(blocking_operation);
+
     // Get the operation data to check if it was executed
     rb_fiber_scheduler_blocking_operation_t *operation = get_blocking_operation(blocking_operation);
     rb_atomic_t current_status = RUBY_ATOMIC_LOAD(operation->status);