fix(pool): bound the PoolInner::close() join and idle drain

[daniel-pinder]

Does your PR solve an issue?

Partially, and deliberately not through a fixes/closes keyword: the
release-path permit leak in #4349 (return_to_pool parking against a silently
dead peer) is addressed by the open PRs #4407, #4350 and #4363, not here.
This PR is the complementary shutdown-side fix: Pool::close() can itself
hang forever, and the accounting a bounded close() exposes wraps.

Is this a breaking change?

No API signature changes. It is a documented behavior change: Pool::close()'s
contract is amended from "wait for all connections" to a bounded, best-effort
close (5 s, one shared deadline), because the previous behavior meant "hang
forever if any caller never returns its connection". The docs on Pool::close
are updated to say exactly what is now promised.

What this does

PoolInner::close() has two unbounded waits:

1. It joins every checked-out connection (semaphore.acquire(permits_to_acquire))
   before draining the idle set. A caller that never returns its
   PoolConnection blocks shutdown indefinitely — the pool holds no handle
   with which to force-close it.
2. It then closes each idle connection serially (idle.live.raw.close().await),
   an un-timed round trip each to a possibly-wedged server.

The join is now bounded by a new CLOSE_JOIN_TIMEOUT (5 s, sibling of the
existing CLOSE_ON_DROP_TIMEOUT); on expiry, close() proceeds to the drain
(mark_closed() has already made that safe). The per-idle closes share one
deadline rather than each taking a fresh timeout, and a deadline-exhausted
drain continues rather than breaks, so the remaining idle entries are
popped and dropped — no waiting is re-introduced (a zero rt::timeout still
polls its future once before elapsing).

Once the join is abandoned, size is stored as zero while a still-checked-out
connection holds a live DecrementSizeGuard; that decrement now saturates. A
plain fetch_sub wrapped the counter to u32::MAX and Pool::size() reported
a lie. No behaviour change while the count is non-zero.

Relationship to other open work (disjoint — races nothing)

• Dropping a PoolConnection whose connection is silently dead leaks the pool permit forever (return_to_pool cleanup never completes) #4349 / fix(pool): bound the entire connection return operation #4407 / fix(pool): bound return_to_pool so a dead connection can't leak its permit #4350 / fix(pool): bound release ping to prevent permit leaks #4363 all touch sqlx-core/src/pool/connection.rs
  (the return_to_pool release path). This PR touches only
  sqlx-core/src/pool/inner.rs and mod.rs — it can merge in any order with
  any of them, and neither substitutes for the other. fix(pool): bound the entire connection return operation #4407's body notes
  "shutdown stalls aren't separately tested" there; this is that half.
• The pop_idle saturating decrement from the same original work is already
  on main via fix(pool): prevent num_idle underflow that wedges maintenance in a CPU spin #4289 ("prevent num_idle underflow...", fixes 100% CPU in sqlx_core::pool::inner::spawn_maintenance_tasks #3645), so this PR
  deliberately leaves that code untouched. Only the DecrementSizeGuard
  saturation (needed because a bounded close() stores size = 0) is added
  here.
• breaking: new sqlx::Pool architecture #3582 (new pool architecture, 0.10+) subsumes this; a 0.9.x-aimed minimal
  fix, this is trivially droppable when breaking: new sqlx::Pool architecture #3582 lands. (Steered by the
  maintainer's comment on fix(pool): bound return_to_pool so a dead connection can't leak its permit #4350: "I already have this fix in breaking: new sqlx::Pool architecture #3582 but that
  won't be merged until 0.10 at the earliest.")

Tests

cargo test -p sqlx-core --all-features — green locally (13 unit + 30 doc
tests). Two new tests, no database server needed (in-memory SQLite), in
inner.rs:

• close_gives_up_on_a_permit_that_is_never_released — a permit is held for
  the life of the test with std::mem::forget; asserts close() returns
  after the bound but not before it. It cannot be shown red-first: without
  the fix the call never returns (that is the bug), so a pre-fix run is a
  hang, not a failure.
• size_saturates_when_an_abandoned_connection_is_dropped — red-first
  verified: with the saturating decrement reverted to fetch_sub, the test
  fails with left: 4294967295, right: 0; restored, it passes.