ci(deploy): right-size max-instances for db-g1-small

[amrtgaber]

Follow-up to #47 / #49 / #50, now that we know the actual DB tier.

What we found

criticalbit-db (the auth-api's Cloud SQL instance in criticalbit-production) is db-f1-micro with no max_connections flag → the tier default, which for f1-micro is small (~25). We're bumping it to db-g1-small (next tier up, ~50 default) — enough breathing room without the dedicated-core tier the aoe2 API needed.

Why this change

The instance cap shipped in #50 was sized for a large tier: MAX_INSTANCES=10 × 10 connections/instance = ~100 peak, which overshoots g1-small's ~50 ceiling. It's been safe only because effective scale is ~1 instance at current traffic.

Drop the cap to MAX_INSTANCES=4 → ~40 peak, under g1-small's default with headroom for the Alembic migrate job and Postgres's reserved connections.

(pool_size 5 + max_overflow 5) × 4 instances = 40 peak  ≤  ~50 (db-g1-small)

Everything else from #49/#50 — configurable pool, pool_pre_ping, pool_recycle, and the stale-revision prune — is unchanged. This only retunes the one number.

Paired infra change (out of repo)

This repo doesn't manage Cloud SQL as code, so the tier bump is applied via gcloud separately:

gcloud sql instances patch criticalbit-db --tier=db-g1-small \
  --project criticalbit-production --account <you>

⚠️ That triggers a short Cloud SQL restart (a few minutes of DB unavailability → auth blips), so run it in a low-traffic window. The two changes are independent and each is strictly safer than today, so order doesn't matter — but they pair to land at 40-peak-under-~50.

Validation

• deploy.yml parses as valid YAML; MAX_INSTANCES=4.
• No Python changed; CI ruff/pytest unaffected.
• Effective max_connections should be re-confirmed on g1-small after the bump (SHOW max_connections;); if it's higher than ~50, MAX_INSTANCES can be raised.