Follow-up: bounded offline kernel/filesystem evidence, not a production root-cause claim Environment: macOS 15.7.9 (24G830), Apple Silicon, CPython 3.11.15 linked to SQLite 3.50.4. The production database is on internal APFS. Its full read-only PRAGMA quick_check has previously returned ok in 2.038s, and on other occasions our progress handler cancelled it after about 30s (SQLITE_INTERRUPT). A consistent SQLite Backup API snapshot passed quick_check and integrity_check, but that comparison was not cache-controlled. We performed one separately authorized offline observation of an existing 3,224,576,000-byte database copy on external APFS, not the production file. The SQL, read-only connection options, and 30s cancellation logic were unchanged. fs_usage was filtered to the reader PID and spindump used -onlyTarget. Important limitation: our capture controller's conservative 48MiB per-stream log cap sent one SIGTERM to the reader after about 10.68s. The overall 256MiB budget was not reached. This was neither completion of quick_check nor reproduction of the 30s cancellation. We will not treat it as either. The database file metadata was unchanged. Excluding the initial pipe-gate wait, the SQLite execution phase had 534 stackshot samples: 532 included pread, 524 apfs_vnop_read, 522 cluster_read_ext, and 405 lck_mtx_sleep; 7 included runnable state. Sample counts overlap and are not exact elapsed-time categories. The retained fs_usage prefix recorded 146,085 pread events and 53,570 RdData[A] events associated with the offline database and its external device (about 1.08GB in reported RdData byte counts). Eight fcntl GETLK/SETLK operations together accounted for about 16 microseconds. Instrumentation overhead and writing the trace output on the same external volume are confounders; there is no claim of a cold-cache control or equivalence to the internal production file. Apple's published xnu-11417.140.69 vfs_cluster.c shows clustered I/O can sleep while issued I/O has not completed. We therefore do not infer a mutex bug merely from lck_mtx_sleep, or infer a failing disk. Specific questions: Does this stack pattern support ordinary clustered-read completion waiting, or can the existing stackshot distinguish it from APFS/kernel contention? Several intermediate frames are unsymbolicated. Which conclusions are justified from this existing report alone? Is there a known supported, mechanism-specific remedy applicable to this evidence that preserves a full current-database quick_check, without changing database contents, bypassing validation, or merely extending a timeout? If no such remedy is supported, is the technically honest conclusion that this evidence cannot provide a reliable fixed 30s completion guarantee, requiring an application time-policy decision rather than another unsubstantiated performance patch? No production database, customer records, credentials, raw memory or private paths are attached. No additional capture, cache purge, parameter tuning or production restart is being performed based on this post.