fix(db): add missing index on request_logs.created_at

[sjawhar]

Summary

request_logs has no index on created_at (10 other indexes exist on this table, none on created_at). Any time-windowed query against it forces a full-table Parallel Seq Scan — most notably a downstream deployment's capture-liveness monitor Lambda, which runs a "rows in the last 15 minutes" check every 5 minutes forever via an EventBridge schedule. At 4.08M rows / 3.7GB, that scan reads ~475k buffer pages and takes ~380ms on every single invocation, regardless of traffic — a fixed, ever-growing tax on the production Aurora cluster's CPU.

This PR is one of two required parts (see Companion PR below) — the index alone or the companion query rewrite alone is not sufficient; both are needed together (confirmed empirically: EXISTS() without this index can be as slow as, or slower than, the original count(*), since the planner has no way to find a matching row early without an index).

What changed

• migrations/postgres/022_add_request_logs_created_at_index.sql: CREATE INDEX CONCURRENTLY IF NOT EXISTS idx_request_logs_created_at ON request_logs (created_at); — CONCURRENTLY because request_logs is a live, multi-million-row production table; a plain CREATE INDEX would hold a lock blocking every in-flight INSERT for the full build duration.
• migrations/sqlite/022_add_request_logs_created_at_index.sql + the matching bundled copy in src/luthien_proxy/utils/sqlite_migrations/ (per migrations/AGENTS.md) — plain CREATE INDEX IF NOT EXISTS (no CONCURRENTLY; SQLite doesn't have/need it).
• Changelog fragment.

Production rollout note (read before deploying)

This migration runs automatically at gateway container startup (docker/start-gateway.sh -> docker/run-migrations.sh) on the next deploy. Two things reviewers/operators should know before that happens:

1. docker/run-migrations.sh invokes psql -f without -v ON_ERROR_STOP=1. By default, psql scripts can exit 0 even after a SQL error mid-script, and the runner unconditionally records the migration as applied in _migrations right after. For most migrations this is low-risk; for this one specifically, an interrupted/failed CREATE INDEX CONCURRENTLY can leave an invalid index behind under the same name, which IF NOT EXISTS would then treat as "already there" on any retry — silently leaving production without a usable index while the tracker says it's applied. This is a pre-existing gap in the migration runner (not introduced by this PR, and out of scope for it), but it's a real risk specifically for this migration. Recommend fixing run-migrations.sh to pass -v ON_ERROR_STOP=1 before/alongside this landing, and verifying pg_index.indisvalid for idx_request_logs_created_at after deploy regardless.
2. Consider decoupling this from normal gateway-startup migration timing. A downstream deployment's ECS service config explicitly notes health_check_grace_period_seconds=120 "covers normal boot; heavy one-time migrations should still be decoupled from app startup." CREATE INDEX CONCURRENTLY on a live 3.7GB table is exactly that kind of heavy one-time migration — if it runs long, new ECS tasks could sit unbound behind the ALB, exceed the grace period, get killed mid-build, and loop the deployment. Recommend running this migration once as a standalone step (e.g. the existing migrations Docker image / Dockerfile.migrations, built for exactly this) against production ahead of the next gateway deploy, then verifying EXPLAIN shows an index scan before rolling the gateway service.

I do not have write access to production Aurora to apply or verify this migration myself (only luthien_admin_iam, a read-only SELECT/EXPLAIN role — confirmed via a live CREATE INDEX attempt returning ERROR: must be owner of table request_logs), so I could not execute either recommendation above myself.

Verification

• uv run pytest tests/luthien_proxy/unit_tests/utils/test_migration_naming.py -m "not integration" -> 54 passed.
• uv run pytest tests/luthien_proxy/integration_tests/test_migration_sync.py -m integration against a fresh local postgres:16-alpine -> 1 passed (Postgres and SQLite migration sets produce equivalent schemas, including this migration).
• Applied the full migration set (docker/run-migrations.sh) against a fresh local Postgres and confirmed it applies cleanly and is correctly tracked/skipped on re-run.
• Seeded a local Postgres with 2.6M synthetic request_logs rows spread over 30 days and ran EXPLAIN ANALYZE before/after:
  • Before (no index): count(*) query -> Parallel Seq Scan, 99.3ms, "Rows Removed by Filter: 863718".
  • After (index + ANALYZE): both the old count(*) query and the new EXISTS(...) query (see companion PR) -> Index Only Scan, <1ms.
• Live production Aurora (read-only, via luthien_admin_iam) confirmed via EXPLAIN (ANALYZE, BUFFERS) that the current count(*) monitor query is still a Parallel Seq Scan today (382.670ms, 475128 buffer hits, "Rows Removed by Filter: 1394125") and that no created_at index exists yet on the live table.

Companion PR

A companion change in a downstream deployment rewrites the capture-monitor Lambda's query from count(*) to EXISTS(...).