Does connection_acquisition_timeout cover initial DNS resolution, or is that phase unbounded?

Following the changes in #1215 and #1275 (connection_acquisition_timeout now covering TLS handshake, routing table fetches, etc.), I wanted to check whether the very first DNS resolution step is included in that coverage or not.

Looking at _pool.py, resolve_address() is called in a plain loop (both in the direct acquire path and in _update_routing_table_from) with no wait_for or deadline check wrapping it. The subsequent connection attempt (fetch_routing_table / socket connect) does receive acquisition_timeout, but resolution itself doesn't appear to.

In practice this means if DNS resolution hangs (e.g. a resolver silently dropping the query, rather than returning NXDOMAIN quickly), there's no bound on that phase at all, regardless of connection_acquisition_timeout or connection_timeout settings. We hit this deploying to a platform where the DNS path to an AuraDB instance was temporarily unreachable: instead of failing fast, verify_connectivity() hung for a long time with no timeout applying, which broke a startup health check with a short deadline.

Is this expected, or is DNS resolution meant to be covered by one of the existing timeout settings and I'm missing where that's enforced? If it's genuinely unbounded, would a dedicated short timeout for just the DNS phase (independent of connection_timeout, which should only start once resolution succeeds) be a reasonable ask, or is this considered out of scope given the recent timeout consolidation work?

Start in _pool.py, tracing resolve_address() in the direct acquire path and _update_routing_table_from, then compare it with the acquisition timeout applied to fetch_routing_table and socket connect. Reproduce the hanging DNS case through verify_connectivity() and inspect the existing timeout tests. Done means the DNS phase's timeout behavior is established and covered by an appropriate test or clearly documented as out of scope.