日志检索与归档协同

对应设计：日志与归档协同重构方案
对应计划：日志归档系统可靠性重构方案

用户问题

管理员需要持续查询 API、登录、业务活动、任务与集成运行记录，并能追溯到已归档历史。当前同一事件可能出现在两个表中，普通“日志清理”会直接删除数据，归档后也没有统一的冷热查询边界，导致排障和审计结果不能稳定复现。

范围

管理端十个既有日志 channel 的在线查询语义、来源标识和历史可用性。
访问、认证、业务、调度、消息、插件运行等日志流的分类、留存与归档资格。
归档批次的可验证性、恢复能力、健康状态与冷数据只读检索。
管理端日志清理操作改为受审计的保留变更流程，不再直接删除日志。

非目标

不改变财务流水、账单、支付、支付回调、失败队列与归档审计的保留政策。
不在本需求中开放归档文件下载、任意路径读取或历史数据编辑。
不将 automation_logs 这类业务幂等状态伪装成可随意删除的普通日志。
不在未经批准的情况下变更当前 30 天在线、180 天归档文件或 Laravel 14 天轮转默认值。

验收标准

[ ] 管理员在同一时间范围查询 API、登录和业务活动时，不会因双写或表切换看到重复、缺失或来源不明的事件。
[ ] 每个可归档 channel 都可说明其在线真源、当前数据范围、归档批次和冷数据可用状态。
[ ] 管理员查看已验证归档历史时，结果能显示归档批次和数据来源；归档不完整时会明确提示，不能以空结果冒充无数据。
[ ] 管理端没有能绕过归档审计直接物理删除数据库日志或改写活动 Laravel 日志文件的入口。
[ ] 自动化任务的进行中状态和已执行幂等记录不受归档影响；重复触发不会因此重复发通知、续费或执行业务动作。
[ ] 日志数据责任人批准各流保留期后，系统只按该批准的流和期限执行定时归档。

发布影响

管理端现有在线日志列表与详情接口保持响应结构；新增冷数据能力采用显式来源/范围参数，不把文件系统路径暴露给前端。
首次切换先覆盖低风险、可验证的日志流；支付网关与未经确认的消息/插件数据不纳入首批删除。
管理员需要获知“在线、已归档、不可用”三种历史状态的含义，运维需确认每分钟 schedule:run 和队列消费健康。

待确认事项

各日志流的法定、合同和运营保留期限及负责人。
历史归档目录是否有仓库外消费者。
冷数据检索的权限、关键词范围和首次开放 channel。