fix(persist): interruptible fsync_worker sleep so persist_stop joins promptly

fsync_worker slept the full wal_sync_ms in one uninterruptible nanosleep()
before re-checking fsync_stop. persist_stop sets the flag and immediately
pthread_join()s, so the join blocked until the in-flight sleep returned —
up to a full wal_sync_ms per teardown. Tests set wal_sync_ms=5000 ("slow
fsync — no races"), so each persist_stop cost ~5s; across the ~7 suites
that use it the cumulative teardown time blew past the 300s controller-test
meson cap, killing the suite with SIGTERM.

Replace the nanosleep with pthread_cond_timedwait on a new fsync_mutex/
fsync_cond (added to persist_t, init in persist_init, destroyed in
persist_fini). persist_stop now sets fsync_stop and signals fsync_cond
under fsync_mutex before joining, so the worker wakes immediately. fdatasync
still runs under p->lock, released before re-acquiring fsync_mutex — no lock
nesting. The "commit: WAIT deadline expired" log lines were unrelated
intentional negative tests (50-300ms), not the cause.

Full controller suite now completes in ~10s (was >300s TIMEOUT); 0 failures.

Logged as bug-604.

src/include/persist.h

@@ -86,6 +86,8 @@ struct persist_s {
     atomic_int      fsync_stop;
     atomic_int      fsync_thread_running;
     pthread_t       fsync_thread;
+    pthread_mutex_t fsync_mutex;   /* guards the fsync timer wait */
+    pthread_cond_t  fsync_cond;    /* signaled by persist_stop for prompt join */
 
     /* Checkpoint (stubs for now — wired in Task 10) */
     atomic_int      checkpoint_requested;