Durable per-user usage rollup and GDPR/PIPL content erasure

[CMGS]

Summary

Closes the two remaining audit/billing gaps identified against the reference architecture: long-horizon per-user usage that survives ledger pruning, and the right-to-erasure hook for retained content.

Durable minute rollup

• New usage_rollup table — per-(minute, tenant, user, model) buckets on all three Store backends — fed by a 60s background task (spawn_usage_rollup).
• Each pass recomputes from the rollup watermark or the trailing 20-minute window, whichever reaches further back: the first run rolls a pre-existing ledger whole, and a stalled task catches up on its own.
• A minute is rolled only after a one-minute settle window, so no in-flight billing write can land in an already-rolled minute — which is what makes the max-upsert sound: buckets only ever grow, and a recompute over a partially pruned ledger can never shrink one. Negative prices are rejected at config load so cost sums stay monotone.
• usage_by_user serves rolled minutes from buckets plus the raw ledger tail (watermark split, minute-aligned bounds), so GET /admin/usage/users stays correct after ledger_max_rows pruning and repeated queries can't drift.
• Postgres elects one replica per pass via an advisory xact lock; periodic tasks skip missed ticks.

Content erasure (GDPR/PIPL)

• DELETE /admin/audit/content?user= erases every retained trace of one end user: retained prompt/response rows, generated batch-result messages (batch_results gained a user_id column), and queued batch inputs — blanked in place across all batch states, so a pending/running item fails at execution instead of running erased content. The content_erase audit entry commits in the same transaction as the deletion.
• Batch inputs are pruned the moment a batch reaches terminal status (same transaction as the status write), so submitted prompt text does not outlive the run.
• Executors defend the capture-to-dispatch window: distributed backends re-read each item's stored row immediately before dispatch and fail closed on any error; local backends check an erasure marker (latest instant per tenant/user, upserted) against the batch's submit instant, so a mid-batch erasure stops the user's remaining items while later batches run normally.
• New DELETE /v1/files/{id} (OpenAI-compatible): files are tenant-owned assets, deleted with one guarded id+tenant statement; SQLite file ids now derive from the non-rewinding AUTOINCREMENT sequence, closing an id-reuse window.
• Documented contract: erasure reaches attributed content; ledger rows and security events carry no content and are kept; anonymous submissions have no erasure subject.

Review

Converged through six adversarial review rounds on the full diff: 18 findings raised, 13 fixed across five fix(review) commits, 4 pushbacks accepted, 1 self-labeled contrived residual accepted (unreachable outside unmerged intermediate states). Key invariants (settle window, monotone buckets, fail-closed dispatch, submit-instant erasure baseline) are documented in code comments and docs/governance.md.

Testing

• cargo fmt --check, cargo clippy --all-targets -- -D warnings clean; cargo test: 320 passed, 0 failed.
• Real Postgres (docker postgres:16-alpine, --test-threads=1): gw-state 45, gw-handler 31, gw-server 83 — exercising the advisory-lock rollup, watermark union, transactional erase + audit, in-place item blanking through a real pending batch, pre-dispatch snapshots, and the guarded file delete.
• Scenario tests pin each fixed finding: first-run backfill, prune-never-shrinks, erasure across batch states, post-erasure batches unaffected, id non-recycling, tenant-scoped erase/delete.