fix(db): range-check operator timeout values against Postgres

pg_timeout_or_default only checked shape, so a well-formed but
unstorable value ("999...9d") reached every pool's after_connect and
Postgres rejected it there — failing all database access, the exact
outcome the fallback exists to avoid. Parse the magnitude, convert it to
milliseconds by unit, and fall back on overflow or anything above the
int GUC ceiling.

The ceiling lives in buzz-db as PG_TIMEOUT_MAX_MILLIS next to the
timeouts it bounds, pinned to the live server by a Postgres-backed test
so it can drift in neither direction.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Signed-off-by: Eli Foster <efoster@squareup.com>

.env.example

@@ -40,7 +40,9 @@ REDIS_URL=redis://localhost:6379
 
 # Postgres statement_timeout and lock_timeout applied to every runtime
 # connection. Accepts an integer (milliseconds) with an optional us/ms/s/min/h/d
-# unit; `0` disables the limit. Schema migrations always run with both lifted.
+# unit; `0` disables the limit. Postgres stores both as int milliseconds, so the
+# ceiling is 2147483647ms (~24 days); anything above it, or otherwise malformed,
+# falls back to the default. Schema migrations always run with both lifted.
 # BUZZ_DB_STATEMENT_TIMEOUT=30s
 # BUZZ_DB_LOCK_TIMEOUT=5s