Fix nsync_waiter_wipe_ zeroing mutexes held by surviving thread after fork

[igravious]

Summary

nsync_waiter_wipe_() (introduced in 98c5847) unconditionally zeroes every mutex pointed to by wipe_mu after fork(). This is incorrect when the forking (surviving) thread holds the mutex — the child inherits the lock but nsync_mu_unlock() sees word=0 and panics:

nsync panic: attempt to nsync_mu_unlock() an nsync_mu not held in write mode

Root cause

1. Thread A acquires mutex M
2. Thread B blocks waiting on M → creates waiter with wipe_mu = M
3. Thread A calls fork()
4. In child, nsync_waiter_wipe_() zeroes M's word (from Thread B's waiter)
5. Thread A tries to unlock M → (0 - MU_WLOCK) underflows → panic

Fix

Before zeroing a mutex in nsync_waiter_wipe_(), check if it's currently held (MU_WLOCK or MU_RLOCK_FIELD bits set). After fork, only the forking thread survives, so any held mutex must be held by it. For held mutexes: preserve lock state but strip stale waiter metadata (MU_WAITING, MU_WRITER_WAITING, etc.) since those waiters are dead. Same logic applied to wipe_cv.

Test plan

• New test test/libc/thread/nsync_fork_wipe_test.c — reproduces the exact crash without the fix, passes with it
• Verified fix resolves 2 test failures in Ruby 4.0.0 bootstrap suite (test_ractor.rb Initial Crypto (RSA/ECDSA) support #1414, Ip6 getifaddrs #1415) which hit this bug via Ractor threads + fork() inside RB_VM_LOCKING()