feat(retention): scheduled data retention cleanup to prevent unbounded DB growth

[suantea]

概述

时序型数据（监控指标、探测结果、WAF 日志、系统日志、DDNS 历史、AI 定时任务日志）此前只进不出，数据库无限膨胀导致越用越慢。本 PR 新增后台保留清理器。

改动

• 新增 service/retention：启动 5 分钟后执行首轮，之后每 24 小时清理一次
• 分批删除（每批 500 行，单表单轮上限 10 万行），避免大 DELETE 长时间占用写锁
• 保留天数经 SystemConfig 键 retention_days 配置（默认 30 天，SystemLog 固定 7 天，上限 365）
• 清理器优雅关闭链入 stopAllFn
• 附 3 个单元测试

验证

• go build / go vet / 全量 go test ./... 通过（含新增 retention 测试）

[suantea]

分支已 restack 到当前 main，请重评

按维护者建议（#87 上「每个 PR 都基于 main 重新创建，PR 之间的修改不要重叠」），本分支已重建。

问题背景：本分支此前的 merge-base 停在 dc2877b（#80 合并点），且 #113–#118 这几个 commit 同时挂在多条分支上，导致 PR 的 GitHub diff 被放大成"巨型回退补丁"，评审看到的是累积 diff 而非本 PR 的真实增量。

本次变更：仅把本分支自身的 commit cherry-pick 到当前 main，内容零改动。

• 旧 head：cc633cb
• 新 head：e5d762f

已验证：go build ./... 通过；本分支自身 patch 与 restack 前逐字节一致（git diff 校验和相同）。

请在新 head 上重评，此时的 diff 只包含本 PR 自己的改动。

[pikachuren]

🙏 感谢 @suantea 提交！
🤖 AI 自动审核声明：本评审报告由 AI 自动生成，当前使用 Claude Opus 5 模型进行分析。
⚠️ AI 分析结果仅供参考，可能存在误判或遗漏。如您发现任何问题或有不同意见，欢迎随时提出讨论和纠正。
⚠️ 重要提醒：即使 AI 评审认为代码质量良好且建议合并，最终是否合并仍需由项目维护者进行人工判定。项目维护者会综合考虑代码质量、项目规划、技术方向、团队资源等多方面因素做出是否合并的决策。

🔄 增量评审：上轮 → 本轮

本轮无新增内容改动 —— 分支被 rebase 到 #85 合入后的 main（dc2877b → 26c4301）。已用 git diff cc633cb4 e5d762fb -- <本PR自身文件> 逐文件核对，结果为空，改动内容与上轮评审时逐字一致（HEAD 变化仅来自 rebase）。

新增改动的问题：无（纯 rebase）。

旧问题解决情况：

• ❌ [原 P0] retention.go:114 db.Where(...).Limit(batchSize).Delete(model) 在 gorm + SQLite 下 Limit 被静默忽略（实测带 Limit(500) 的删除删掉了 1234 行）→ 未修复
• ❌ [原 P1] 5 张表的时间列用不上索引（复合索引非首列）→ 未修复
• ❌ [原 P1] 清理过程无 context / 无超时 / 无 panic 隔离 → 未修复
• ❌ [原 P1] retention.go:79 return func(){ close(done) } 非幂等（重复调用 panic）→ 未修复

🎯 结论：🔄 Request Changes — 内容未变，上轮问题状态同上

[pikachuren]

🙏 感谢 @suantea 提交！
🤖 AI 自动审核声明。⚠️ 最终合并决策由项目维护者判定。

🎯 结论

🔄 Request Changes — 与 #110 存在功能重复，需先协调（非本 PR 自身质量问题）

📖 概要

定时数据保留清理 · 防止 DB 无限增长
核心改动：独立 retention 模块，分批删除 6 张时序表过期数据，保留天数可配置

🚨 关键问题

P0（需协调，非缺陷）：

• ⚠️ 与 #110 的 monitor.runRetention/waf.StartRetention 功能重复（详见 #110 评审），两者若同时合并会产生策略冲突。本 PR 实现质量更高（分批 500 行/单表上限 10 万行防积压、可配置天数、覆盖面更全含 SystemLog/DDNSHistory/AiCronLog），建议以本 PR 为准，从 #110 摘除重复的清理逻辑。

P2：

• 💡 retention.go 缺少 sync.Once/防重入保护，若 New().Start() 被误调用两次会产生并发 DELETE。
• 💡 单表单轮清理上限固定 10 万行，老部署首次升级若堆积超过此量需多轮 24 小时周期才能追平，建议记录"未清理完"日志提示。

代码本身工程质量是本批 PR 中较好的一个：分批策略合理、默认值兜底完善、有对应测试。

🎯 结论：🔄 Request Changes — 需先与 #110 协调去重（建议保留本 PR），P2 问题可选跟进