feat(relay): make Postgres pool size configurable, default 50

[tlongwell-block]

Summary

• Raise the relay's Postgres pool cap from the buzz-db default of 20 to 50 per pool, and expose BUZZ_DB_POOL_SIZE for per-deploy tuning
• Applies to the writer pool and, when READ_DATABASE_URL is set, the reader pool; zero/unparsable values fall back to the default
• The buzz-db library default is unchanged — only the relay opts into the larger cap

Why

During the 2026-07-27 18:40–19:05Z traffic burst on bb-public, per-pod PG pools pinned at 20 fleet-wide and ~380 requests failed on the 3s acquire timeout — membership checks, channel access lookups, and historical queries returning errors to users. The database was nowhere near a limit: Aurora (db.r8g.8xlarge, ~5,000 max connections) sat at 19% CPU, 201 connections (~4% of capacity), commit latency flat at 0.01ms.

The 20-connection default was sized for "four relay pods against PG max_connections=100" (the comment in buzz-db says exactly that). Production now runs 12–15 pods against Aurora — the per-pod cap is the binding constraint, not the DB.

Budget at the new default: 15 pods × (50 writer + 50 reader + 5 audit) ≈ 1,575 potential connections, ~30% of Aurora's ceiling — and actual usage stays demand-driven (min_connections stays 2, connections only open under load).

Same shape as #2521 (BUZZ_REDIS_POOL_SIZE), which fixed the identical class of ceiling on the Redis side.

Testing

• cargo test -p buzz-relay: 762 passed, 1 failed — the lone red is api::mesh_demo::tests::demo_join_forwarded_arm_round_trips_echo, the known pre-existing flake; it fails identically on clean main at the same SHA (verified via git stash / rerun)
• New test db_pool_size_env_override_and_invalid_fallback covers override, zero, and unparsable fallback
• defaults_are_valid extended to pin the new default
• cargo clippy -p buzz-relay --all-targets -- -D warnings and cargo fmt --check clean