[kacy]

Under the green backend, every Mutex.unlock took the mutex's internal waiter lock to drain a list of parked green tasks that is almost always empty. On lock_sweep/breaker (one breaker per task, so the locks are uncontended), pith_mutex_unlock was 56% of the profile.

The state word now has a third value: 2 means "held, with green tasks registered". A waiter moves the state from 1 to 2 under the waiter lock before it registers. If the lock was released in between, that move fails on the 0 and the waiter retries the acquire instead of parking. unlock swaps in 0 and takes the waiter lock only when the old value was 2. This is the usual futex register-then-recheck. An os-thread waiter still spins on the 0 to 1 compare-exchange and never sets 2.

Interleaved medians of 7 at 16 workers, main against this branch:

row	main	this branch
lock_sweep/breaker	146 ms	112 ms

The other lock_sweep and metrics_contention rows and cpu_parallel_sync are within noise. Reruns of the two labels rows with 15 trials gave medians of 51.7 vs 52.3 and 92.6 vs 92.0 ms.

Local corpus, leak, memcheck, green (including green-mutex), result-box, cargo test, seed, TLS-barrier and panic gates pass.