feat(selfhost): add bounded retention for webhook_events, audit_events, ai_usage_events, product_usage_events, agent_context_snapshots

[JSONbored]

Context

signal_snapshots was already fixed to a bounded, deduped latest-per-key retention (#3810/#3857). A follow-up sweep found five more tables that grow forever with no prune/delete path anywhere in src/:

• webhookEvents (src/db/schema.ts) — one row per inbound webhook delivery, never deduped or aged out.
• auditEvents (src/db/schema.ts) — one row per contributor-affecting decision, written from 170+ call sites via recordAuditEvent.
• aiUsageEvents (src/db/schema.ts) — one row per AI review/summary call; only needed for the rolling daily-neuron-budget window (sumAiEstimatedNeuronsSince).
• productUsageEvents (src/db/schema.ts) — rolled up daily into productUsageDailyRollups, but the raw per-event rows are never deleted even after being folded into that rollup.
• agentContextSnapshots (src/db/schema.ts) — one payload blob per agent run, capped only by a per-runId read .limit(50), not a delete.

None of the backup/litestream services in docker-compose.yml touch app-level row retention — they only snapshot/replicate the whole database file, so this is a genuine unbounded growth vector distinct from #3810 (which is scoped to signal_snapshots + central-cloud D1 size probing/alerting specifically).

Requirements

• Add a periodic maintenance pass (alongside the existing maybeRunAgentMaintenance in src/queue/processors.ts) that prunes rows older than a configurable retention window for webhook_events, audit_events, and agent_context_snapshots.
• For ai_usage_events, prune while always preserving at least the current UTC day (needed by sumAiEstimatedNeuronsSince).
• For product_usage_events, prune rows once they are older than the oldest rollup window they still need to contribute to (PRODUCT_USAGE_RETENTION_MAX_WINDOW_DAYS, already computed in src/db/repositories.ts).
• Make each retention window configurable with sane defaults; fail-safe (a pruning failure must never affect the review/gate path).

Acceptance criteria

• All five tables have a bounded, tested retention mechanism.
• Existing rollup/budget-window consumers (sumAiEstimatedNeuronsSince, productUsageDailyRollups) are unaffected by pruning.
• 100% branch coverage on the new pruning logic; a regression test proves pruning doesn't remove rows still needed by a live consumer.

Parent: #1667

[linear-code]

JSO-2856

[JSONbored]

Correction after implementation research:

• audit_events, ai_usage_events, product_usage_events already have working, cron-scheduled retention via RETENTION_POLICY in src/db/retention.ts (pruneExpiredRecords, dispatched by the prune-retention job type, enqueued daily from src/index.ts's scheduled handler). The original audit's grep -rn ".delete(" check missed this because the deletes are dynamic SQL strings (DELETE FROM ${rule.table} WHERE ...), not literal Drizzle .delete(table) calls.
• webhook_events was deliberately excluded from retention by a prior fix (commit 67c11f2e, "fix(db): preserve webhook replay cache during retention" — GitHub can redeliver a webhook long after the original event, and this table is the idempotency/dedup record that detects that). There's a dedicated regression test (test/unit/retention.test.ts, "the policy only targets append-only/log/snapshot tables") asserting webhook_events is never in RETENTION_POLICY. Adding it back would reintroduce that fixed bug.
• agent_context_snapshots is the one table from the original finding that's genuinely still unaddressed (a per-run diagnostic payload blob, capped only by a .limit(50) read, never deleted).

Scoping this issue down to just agent_context_snapshots.