Distinguishing WAL checkpoint wait from connection pool exhaustion in SQLite

The goal is to understand how SQLite WAL mode interacts with an application-level connection pool under high concurrency, and whether apparent pool exhaustion reflects lock wait or actual resource depletion.

WAL retains read locks on the database file until a checkpoint completes, which can make readers appear blocked. The per-connection PRAGMA busy_timeout does not change checkpoint latency. Checkpoint frequency and duration vary by platform and SQLite build, and VFS behavior such as mmap can introduce additional thread blocking that mimics pool exhaustion.

This raises an unresolved design question about observable liveness.

Does SQLite expose a way to distinguish a connection waiting for a WAL lock from a connection waiting for a pool slot? Which PRAGMAs affect checkpoint timing independently of busy_timeout? When does a reader remain blocked by an uncheckpointed writer in WAL mode?