Slow-fsync test disk: use FUSE, not an LD_PRELOAD fsync shim

To test that a server stays responsive while fsync is slow, an LD_PRELOAD shim that delays fsync/fdatasync is too narrow. io_uring FSYNC, O_SYNC/O_DSYNC/RWF_DSYNC writes, msync and raw syscall(SYS_fsync) all bypass it. A small libfuse3 low-level passthrough that delays FUSE_FSYNC and FUSE_FSYNCDIR catches all of those, because the kernel turns sync writes into FUSE fsyncs. Delay with a timer queue, so a waiting fsync doesn't hold a daemon thread. sync/syncfs/sync_file_range never reach FUSE, so keep a preload shim just for those. Gotchas: the kernel holds the inode lock during a pending FUSE fsync, so writes to the same file wait; use one node per backing (dev, ino) so hard links stay coherent. Also, Docker's default seccomp profile blocks io_uring_setup, so add seccomp=unconfined (or --privileged) or io_uring servers can't start.