What problem do you want to solve?
目前 raw usage_events 超过 90 个本地自然日后会进入 usage_events_archive 并永久增长。长时间运行时，管理员需要控制 SQLite 原始事件体积，同时永久保留按日汇总和 API key 归属。
原始事件一旦删除就无法再按未来的新 schema / 统计口径重放，因此该取舍需要是显式配置，而不是隐式清理。
What would you like to happen?
建议增加：
USAGE_RAW_EVENT_RETENTION_DAYS=365
- 默认总保留 365 个本地自然日。
0 表示永久保留。- 非零值小于 90 时拒绝启动，因为 hot
usage_events 固定保留 90 天。
- 每日维护只从
usage_events_archive 删除早于 cutoff 的 raw rows。
- 使用有上限的小事务批次，并在批次间响应 cancellation。
usage_overview_daily_stats 等 daily aggregates 与 cpa_api_keys 永久保留。- 清理后仍执行现有 conditional vacuum 判断，并记录 deleted count / status。
Additional context
这与 #409 的历史数据导入互补：导入解决迁移，retention 决定本地 raw event 可供重建多久。
一个已实现并覆盖默认值、0、90 天下限、cutoff、900-row batching、cancellation、永久数据边界和 vacuum 的参考 commit：
Tranxmart@40d0ef9
What problem do you want to solve?
目前 raw
usage_events超过 90 个本地自然日后会进入usage_events_archive并永久增长。长时间运行时，管理员需要控制 SQLite 原始事件体积，同时永久保留按日汇总和 API key 归属。原始事件一旦删除就无法再按未来的新 schema / 统计口径重放，因此该取舍需要是显式配置，而不是隐式清理。
What would you like to happen?
建议增加：
0表示永久保留。usage_events固定保留 90 天。usage_events_archive删除早于 cutoff 的 raw rows。usage_overview_daily_stats等 daily aggregates 与cpa_api_keys永久保留。Additional context
这与 #409 的历史数据导入互补：导入解决迁移，retention 决定本地 raw event 可供重建多久。
一个已实现并覆盖默认值、
0、90 天下限、cutoff、900-row batching、cancellation、永久数据边界和 vacuum 的参考 commit：Tranxmart@40d0ef9