fix(db): bound runtime Postgres statements and lock waits

[jmecom]

This change applies a statement_timeout and lock_timeout whenever the writer, lazy replica reader, audit, and search pools establish a connection. The limits prevent slow statements and lock waits from holding pool capacity indefinitely. Legitimate work exceeding those bounds will now be canceled and must be retried or redesigned.

The bounds are runtime-only. Schema migrations run on a connection with both limits lifted, and that connection is closed rather than returned to the pool: an index build on a populated table, or an ACCESS EXCLUSIVE wait behind live traffic, routinely outlasts them, and startup treats a migration failure as fatal. sqlx also takes its migration advisory lock as a single waiting statement, so a second replica rolling out would be canceled mid-wait instead of queueing behind the first.

lock_timeout bounds heavyweight and row lock waits. Advisory-lock waits — event replacement, the per-community audit lock, sqlx migrations — are bounded by statement_timeout instead.

Both values are configurable through DbConfig, wired to BUZZ_DB_STATEMENT_TIMEOUT and BUZZ_DB_LOCK_TIMEOUT, defaulting to 30s and 5s. An operator running a backfill or working an incident does not need a code change, and 0 disables a limit. A malformed value falls back to the default with a warning rather than failing config: handing it to Postgres would fail every after_connect and take all database access with it.

Testing

• cargo test -p buzz-db --lib at 6f8e115: 94 passed, 153 ignored (Postgres)
• cargo test -p buzz-relay --lib at 6f8e115: 830 passed, 10 failed — every failure is pre-existing and needs a live Postgres/Redis, verified by diffing the failure set against the same run with these changes stashed
• cargo clippy -p buzz-db -p buzz-relay --all-targets -- -D warnings and cargo fmt -- --check: clean
• git diff --check origin/main...codex/security-postgres-timeouts
• Rebased onto origin/main at 5c98932

Unit tests cover the timeout parser (Postgres spellings accepted; empty, unit-less junk, and 30 seconds rejected in favor of the default) and the env plumbing end to end through Config::from_env.

Postgres-backed tests, run locally against postgres:17-alpine:

• armed_pool_rejects_old_channel_inserts_through_public_api — SHOW statement_timeout / SHOW lock_timeout are the configured values on both the writer and reader pools
• migration_connection_is_unbounded_and_is_retired_not_reused — the migrator's connection reports 0 for both, and a single-slot pool hands out a freshly configured connection afterwards
• migrations_ignore_runtime_timeouts_and_leak_no_relaxed_session — a real db.migrate() against a tight-timeout Db succeeds, and every connection in the pool still carries the configured limits

The exemption assertions were checked against a neutered implementation — a no-op lift and a drop instead of a close each fail the test. A timing-based test does not discriminate here: on an empty database every migration statement finishes well inside the runtime cap, so it passes with or without the exemption.

Still unverified: these three are #[ignore = "requires Postgres"] and CI's ignored-test jobs select by explicit filter, so they run only when someone runs them by hand. The full --ignored buzz-db suite was not run to completion locally (it exceeds a 10-minute budget); the three above were run individually.

Originating Buzz thread: buzz://message?channel=3928fe05-df61-4b5d-b9c7-d623b9b10ea1&id=3c6c02312f763fbe0d2bfc33a6c1a362f91d0354f3d18b039cf7a0558c1439d1

[elifoster-block]

Excluded migrations from the timeouts and set the timeouts as a DBconfig option.