fix(postgres): match psycopg_pool's one-hour default pool max_lifetime

Why

The driver aims to be a psycopg drop-in, and its DEFAULT_POOL_MAX_LIFETIME of 1800 s diverged from psycopg_pool's 3600 s default without a supporting measurement.

With the vendored tokio-postgres buffer cap now bounding per-connection memory, recycling frequency no longer carries the memory rationale it was chosen under. Benchmarks against the glitchtip ingest workload (steady envelope traffic, log-normal payload sizes) show the lifetime lever saturates — windows 12×/30× shorter than one hour land on the same RSS growth floor — while more frequent recycling measurably increases allocator churn (evicted connection buffers become freed-but-binned heap pages). Where a default choice ties on merit, drop-in consistency with psycopg wins.

Change

DEFAULT_POOL_MAX_LIFETIME 1800.0 → 3600.0 (constant + docstrings). Behavior otherwise unchanged: OPTIONS["pool"]["max_lifetime"] still overrides, explicit 0 still disables recycling, and the deterministic ±10% per-connection jitter is untouched.

---

Written with AI assistance (Claude); human review required.