🐛 云同步不再随 SW 冷启动触发，闹钟周期改为 30 分钟 - #1678

Checklist / 检查清单

• Fixes mentioned issues / 修复已提及的问题
• Code reviewed by human / 代码通过人工检查
• Changes tested / 已完成测试

Description / 描述

Close #1670

背景

用户把云同步接到 S3 桶后发现「同步频率设成每天，结果每分钟调用五次接口」。

MV3 的 Service Worker 空闲即被回收，每次冷启动都会重跑 init() 并用当前配置回调一次
cloud_sync 的 watch（SystemConfig.watch 注册时会立即执行一次回调）。
cloudSyncConfigChange 在无 previous 时会直接跑一次全量 syncOnce ——
而 agentTaskScheduler 闹钟每分钟唤醒一次 SW，于是实际同步频率退化成「每分钟一轮」，
60 分钟的 cloudSync 闹钟形同虚设。

v1.4.0 与当前 main 都有这个问题（v1.4.0 连配置等价判重都没有，另外还多一个
extension_initialized 触发点）。

顺带说明：云同步并没有频率设置项，设置页上紧挨着同步卡片的「每天」是脚本更新检查周期，
报告人把它当成同步周期了。

本次改动

• 冷启动只 ensureCloudSyncAlarm()，不再同步；周期同步交给闹钟。
• cloudSync 闹钟周期 60 → 30 分钟。
• 闹钟成为启用后唯一的周期性入口，处理器从裸的 getCloudSync → buildFileSystem → syncOnce
  改走 synchronize.cloudSyncOnce()（自带启用校验与失败状态写入）并补 .catch ——
  原来连接失败会在每轮闹钟留下一个未捕获 rejection。

不变：勾选启用的瞬间仍立即同步一次、设置页「立即同步」按钮、脚本安装/删除的事件推送。

第二个提交是顺带修的 OneDrive 建目录问题（Graph 个人版对 special/ 寻址的 POST children
返回 400 invalidRequest，改用 /me/drive/items/{approotId} 寻址）。

验证

单元测试按 TDD 先写 RED 再实现：

$ npx vitest run src/app/service/service_worker/synchronize.test.ts -t "云同步配置变更调度"
AssertionError: expected "buildFileSystem" to not be called at all, but actually been called 1 times
  ❯ synchronize.test.ts:2495  expect(buildFileSystem).not.toHaveBeenCalled();

$ npx vitest run --no-coverage        # 实现后，连跑 3 次
Test Files  329 passed (329)
Tests  3732 passed (3732)

$ npx tsc --noEmit                    # exit 0
$ npx prettier --check / npx eslint   # exit 0

真机复现与验收（真实 MinIO，扩展的 S3 端点指向一个逐请求记账的透传代理；
脱离调试器运行，因为 CDP 附着会阻止 MV3 SW 被回收、这个 bug 就不出现）：

修复前的轮次起点：02:09:57 / 02:10:57 / 02:11:58 / 02:12:57 / 02:14:00 / 02:15:59 / 02:16:57，
每轮 HEAD + LIST + GET + PUT + LIST，与 issue 里贴的 5 条日志一致。

修复后仍验证了三条该保留的路径：

• 勾选「启用」瞬间同步一次（02:37:52 一轮）；
• 闹钟仍触发同步：把闹钟排程临时改成 1 分钟以免等 30 分钟，02:39:17 排程 →
  02:39:17.264 起一轮（只替换触发时刻，处理器与同步链路是真实的）；
• chrome.alarms.getAll() 实测 cloudSync period=30min。

.catch 单独验证：停掉代理制造真实连接失败，日志出现 cloud sync alarm failed，
整个会话 [exception] 计数为 0。

另做了一次不经过代理的独立回读（扩展页 chrome.storage.local）：空闲窗口后
lastSyncAt 仍停在 02:39:18、enable=true；而这次回读本身又是一次冷启动，
lastSyncAt 未推进。

已知限制

• 跨设备拉取延迟从「近乎实时」（此前是 bug 导致的每分钟同步）变为最长 30 分钟。
  同步周期仍是硬编码，可配置化是单独的 feature。
• agentTaskScheduler 仍每分钟唤醒一次 SW，无条件创建、不受 Agent 开关约束。
  修完后它不再产生 S3 请求，但每分钟冷启一次 SW 的开销仍在，属另一个 issue，本 PR 未动。