Fiber thread bridge for blocking_lock coop interleaving

[Copilot]

The panic/unwind PoC for blocking_lock can't resume at the call site — Rust's async fn state machine poisons after an unwind, limiting it to manual Future::poll impls that restart cleanly. The correct fix is a thread-per-fiber bridge: the OS thread literally parks at the blocking_lock call site via a condvar and resumes there when the coop scheduler grants the operation.

Fiber infrastructure (task/fiber.rs)

• FiberShared<R> — two condvars (fiber_wakeup, executor_wakeup) for executor↔fiber signaling; FiberStatus enum (WillRun / Running / Parked(Operation) / Done)
• FiberContext trait + CURRENT_FIBER thread-local — lets blocking_lock detect it is executing inside a fiber
• FiberFuture<R>: Future — drives the fiber; blocks the executor thread while the fiber runs (safe: Bach is single-threaded), returns Poll::Pending after the fiber parks and registers its Operation with the coop scheduler
• spawn_fiber(f) — convenience wrapper over task::spawn(FiberFuture::new(f))

blocking_lock / blocking_lock_owned

In fiber + active-coop context, always calls park_for_operation before try_lock — mirroring the lock_op.acquire().await in the async lock() path. This makes every acquisition visible to the scheduler so all orderings are explored exhaustively. Falls back to the existing panic/unwind mechanism for non-fiber manual Future::poll impls (existing tests unchanged).

Usage

let mutex = Arc::new(Mutex::new(0usize));

bach::task::spawn_fiber({
    let mutex = mutex.clone();
    move || {
        // Ordinary synchronous code — resumes here after coop grants the lock,
        // not from the top of poll().
        let mut guard = mutex.blocking_lock();
        *guard += 1;
    }
})
.primary()
.spawn_named("worker");

The mutex_blocking_lock_fiber snapshot test confirms both acquisition orderings are explored when two fiber tasks contend for the same mutex.