perf: remove statement_timeout, keep health_db isolation + pool timeout

[ety001]

Summary

Reverts the statement_timeout=30s change from PR #375 while keeping all four safe changes.

Background

PR #375 introduced statement_timeout=30000 (via libpq options string) to cap runaway queries server-side. In production (2026-08-01) this caused a query amplification loop:

PG cancels query at 30s → releases connection
  → hivemind async handler NOT cancelled → grabs new connection
    → new query also times out → repeat
      → RDS flooded with retried queries → I/O saturates
        → simple queries (200ms normal) take 341s+
          → hivemind memory piles to 99% (8GB c5.xlarge)

Root cause: statement_timeout kills the PG query but does NOT cancel the Python async coroutine (aiopg has no mechanism for this). The freed connection is immediately reused for a retried query, creating more concurrent load than before.

Changes

Removed:

• STATEMENT_TIMEOUT_MS = 30000 constant
• options string construction in init() (-c statement_timeout=30000)
• query dict merge logic (back to **conf.query directly)

Kept (from PR #375):

• ✅ health_db: isolated maxsize=1 engine for /health and /head_age
• ✅ MAX_DEPTH=50 / MAX_THREAD_POSTS=500: bounds _load_discussion recursion
• ✅ hide_id lookups cached (300s TTL): reduces per-request DB connections
• ✅ Pool acquire timeout=10 (from PR perf: fix N+1 queries in load_posts_keyed, add DB pool timeout #374)

Why Now

Inbound load is now controlled at the openresty layer (steemit/openresty#18): get_state dual-track rate limiting (internal aggregate 30r/s + external per-IP 10r/s). This reduces hivemind inbound traffic at the source rather than killing queries server-side, avoiding the async-handler-not-cancelled trap entirely.

After openresty rate limiting deployment, hivemind slow queries dropped from 10k+/5min to 0-71/5min, and the system is healthy. The remaining safe changes (health_db isolation, recursion caps, cache) further harden hivemind without the statement_timeout risk.

Verification

• db.py syntax verified (ast.parse)
• No statement_timeout / STATEMENT_TIMEOUT / timeout_opt references remain
• health_db and conf.query usage intact
• Unit tests from PR perf: cap query time, bound discussion recursion, isolate health checks #375 (tests/bridge_thread/) unchanged — they test the thread recursion caps, not statement_timeout