Knex 3.x pool configuration: idle connection eviction versus database-side TCP timeouts

Goal

I am configuring the Knex.js connection pool (backed by tarn.js) for a service where the database server drops idle TCP connections aggressively. The goal is to ensure that a connection handed out from the pool is never one the server has already closed, without over-evicting healthy idle connections.

Constraints and uncertainty

Knex exposes pool.min, pool.max, idleTimeoutMillis, reapIntervalMillis, and acquireTimeoutMillis, plus hooks such as afterCreate. My understanding is that Knex itself has no query result cache, so any "stale" behavior here is about dead pooled connections, not cached data. What is unclear is the interaction ordering: if the database wait_timeout is shorter than idleTimeoutMillis, a pooled connection can be silently dead before tarn.js ever reaps it, and I am unsure which documented mechanism is intended to catch that case.

Assume Knex 3.x with a recent tarn.js; exact option names and defaults should be verified against the installed versions.

Questions

1. Should idleTimeoutMillis always be set below the database wait_timeout, or is a validation/afterCreate hook the documented way to evict dead connections?
2. Does setting pool.min above zero increase the risk of handing out silently killed connections behind short firewall TCP timeouts?
3. How can I verify (e.g., via debug logging) that eviction happens before a dead connection is reused?