Fix thread-safety warnings in Mutex::lock/unlock for newer clang

[mturnpaugh]

Problem

After upgrading to CMake 4.4.0 (which bundles AppleClang 17+), the pipeline started failing with:

src/mutex.h:79: error: mutex 'mut_' is still held at the end of function [-Werror,-Wthread-safety-analysis]
  void lock() ACQUIRE() { mut_.lock(); }
src/mutex.h:80: error: releasing mutex 'mut_' that was not held [-Werror,-Wthread-safety-analysis]
  void unlock() RELEASE() { mut_.unlock(); }

Root Cause

The Mutex class is declared as a CAPABILITY("mutex") wrapper. Its lock() and unlock() methods are annotated with ACQUIRE() and RELEASE() (no argument = acquires/releases *this).

The issue is that std::mutex::lock() and std::mutex::unlock() in libc++ are themselves annotated with clang thread-safety attributes (acquire_capability / release_capability). When Mutex::lock() calls mut_.lock(), clang's thread-safety analysis tracks mut_ (the inner std::mutex) as being acquired — but the outer function is annotated as acquiring *this (the Mutex capability), not mut_. Clang sees a std::mutex acquired and never released within lock(), producing the error.

Newer clang enforces this more strictly, which is why it worked before and breaks now.

Fix

Call pthread_mutex_lock / pthread_mutex_unlock directly via mut_.native_handle() instead of going through std::mutex::lock() / unlock(). The pthread_* functions have no clang thread-safety annotations, so the analysis does not track mut_ as a separate capability being acquired. The behavior is identical at runtime — std::mutex::native_handle() returns the underlying pthread_mutex_t*.

The ACQUIRE() / RELEASE() annotations on the public API are preserved, so callers of Mutex are still checked correctly by the thread-safety analysis.

Why other approaches didn't work

• ACQUIRE(mut_) — wrong: annotates the function as acquiring the inner std::mutex object rather than the Mutex capability itself, which confuses callers.
• NO_THREAD_SAFETY_ANALYSIS on the function — insufficient: clang's thread-safety analysis is function-scoped and still reports the held lock at end of function.
• _Pragma("clang diagnostic ignored") — insufficient: suppresses the inline diagnostic but not the end-of-function analysis report.
• Private helper methods with NO_THREAD_SAFETY_ANALYSIS — same problem; the inner std::mutex annotations still fire from any calling context.