[Bug] .env 的 AGENT_EVENT_ALERT_RULES_JSON 与 alert_rules 表两套存储互不同步，页面建的规则 schedule 轮询看不到

环境

项	值
软件版本	v3.32.0（桌面版 Electron）
系统	Windows 11 x64
配置	SCHEDULE_ENABLED=true、AGENT_EVENT_MONITOR_ENABLED=true

问题：告警规则存在两套互不相通的存储

存储	写入方式	谁消费	Web 页面可见
.env 的 AGENT_EVENT_ALERT_RULES_JSON	手改 .env + 重启	schedule 后台轮询（agent_event_monitor）	❌ 看不到
SQLite alert_rules 表	POST /api/v1/alerts/rules（Web 告警中心）	告警中心手动检查 / 测试	✅ 可见

实测证据：把 6 条规则写进 .env 的 AGENT_EVENT_ALERT_RULES_JSON 并重启后， GET /api/v1/alerts/rules 仍返回 total=0（DB 表为空）；改走 API 建规则 → total=6，但 .env 那份不变。

用户侧的实际后果

1. 幽灵告警：用户在 Web 页面清仓某股票并删掉相关规则后，.env 里那份不会跟着变。 若 .env 份里还有旧持仓的规则，SCHEDULE_ENABLED=true 时轮询继续对已清仓股票求值告警。 （实测复现：已清仓股票的规则残留在 .env，DB 已无）
2. 用户认知混乱：页面里看不到 schedule 实际消费的规则，无法判断"到底哪些规则在生效"。
3. 手改 .env 的规则在告警中心不可见、不可测、不可管理——两套能力割裂。

已排除「配置问题」

对照上游 .env.example：与告警规则相关的配置项只有 AGENT_EVENT_ALERT_RULES_JSON 一个 （模板 line 557），没有任何"让 schedule 改读 DB"或"双向同步"的开关 → 这是设计层面的双数据源问题，无法靠用户配置规避。

说明：本例当前已手工把 .env 那份同步成与 DB 一致（5 条），所以暂未产生实际误报； 但只要用户在 Web 端增删规则而未同步改 .env，两套就会再次分叉——这正是它值得修的理由。

建议修复方向

1. 合并为单一数据源：以 alert_rules 表为准，AGENT_EVENT_ALERT_RULES_JSON 仅作首次迁移的导入源；
2. 或至少做到双向同步：Web 端增删改时写回 .env，schedule 轮询改读 DB；
3. 短期兜底：文档中明确二者职责边界，并在告警中心页面展示"schedule 轮询消费的规则集"， 避免用户以为页面列表就是全部生效规则。

本 issue 由用户实际使用中的「已清仓股票仍在告警」现象切入排查，以上行为均实测复现。