fix(automation): 修正调度口径——作业每 5 分钟跑一轮，interval_seconds 只是单行重检间隔

P1a 把两个「间隔」混成了一个：next_run_at 用的是 job.interval_seconds，于是
作业 6 小时才跑一轮、每轮 200 条 = 800 条/天，全库 12,881 条要 16 天才能过
一遍 —— 等于没巡检，与规划里「账号 6 小时内被查一次」的目标差了两个数量级。

按规划原意修正：
- TICK_SECONDS 60 → 300：作业每个 tick（5 分钟）跑一轮；
- next_run_at 改为 finished + TICK_SECONDS，不再用 interval_seconds；
- interval_seconds 只作为「同一行多久重新检测」的选行 cutoff（选行逻辑本来就
  是这么用的，无需改）；
- 容量口径随之更新：5 分钟一轮 × 200 条 = 40 条/分钟 ≥ 需要的 36 条/分钟，
  冷启动约 5.4 小时覆盖全库，稳态每轮一百多条；
- 前端标签由「巡检周期(小时)」改为「单账号重检间隔(小时)」，说明文案写清
  「每 5 分钟跑一轮」，避免运维误以为是作业周期。

同步更新规划文档 §7.2/§7.3（含两个间隔不能混的说明）与附录 C 的三段上线
步骤（立即跑一次 → 每轮 50 观察 → 每轮 200 启用）。

web/backend/services/automation/__init__.py

@@ -46,7 +46,9 @@ def register_default_jobs() -> None:
         JobSpec(
             key=CK_HEALTH_KEY,
             title="CK 自动巡检",
-            # 6 小时一轮；全库 12,881 条按此反推 batch_size=200（见规划附录 C）。
+            # interval_seconds = 单账号多久重新检测一次（不是作业周期；
+            # 作业每个 tick 都跑）。全库 12,881 条按 5 分钟一轮、单轮 200 条
+            # 反推，吞吐 40 条/分钟，够 6 小时内覆盖一遍（规划 §7.3）。
             interval_seconds=6 * 3600,
             batch_size=200,
             concurrency=5,