feat(postgres): Add connection pool support via `WithConnectionPool`.

Introduces first-class support for routing application traffic through a connection pool (e.g. PgBouncer) while allowing migration clients to bypass the pool and connect directly to the primary.

New option: WithConnectionPool(bool)

postgres.New now accepts WithConnectionPool(bool), defaulting to true. Pass WithConnectionPool(false) to explicitly disable pool routing — the intended usage for migration clients, which must bypass PgBouncer to avoid statement-timeout kills on long-running queries.

Host and port resolution

When the connection pool is enabled, host and port resolution follows a priority chain before falling back to the primary address:

pool_host config → pool_host secret → host config → host secret
pool_port config → pool_port secret → port config → port secret

When the connection pool is disabled, pool_host/pool_port are ignored entirely and the chain collapses to the primary address. This means pooler-less deployments (e.g. Caproni) work without any configuration change.

CrunchyData projection preset

The CrunchyData projection preset is extended with pgbouncer-host and pgbouncer-port Secret key mappings. When PgBouncer is enabled in a CrunchyData cluster, those keys are present in the pguser Secret and will be picked up automatically — no explicit Helm values required. Deployments without a pooler fall through to the existing host/port keys.

Pool bypass for migration clients

When WithConnectionPool(false) is set, maxConns is capped at 1. This prevents migration clients from opening a pool of direct primary connections, which would defeat the purpose of bypassing PgBouncer.

Bumps Fairway dependency to pick up pool_host/pool_port fields on the PostgreSQL proto message (runway/team#920, Fairway side).

Issue: gitlab-com/gl-infra/platform/runway/team#920 (closed)