perf(automation): 账号资料补全提速到 ~3.2 小时（原默认值要 5 天多）

用户反馈「几个小时补充完成就行吧，几天也太慢了」——**对，是我把调度设得太保守**。

## 算一下原默认值有多离谱

    30 个 / 30 分钟 = 60 个/小时  →  7,784 个要 **130 小时（5 天多）**

（我上一条说"3 天"还算乐观了。）

而**试水实测的吞吐**是 200 个 / 131 秒（并发 3）= **1.53 个/秒 ≈ 5,500 个/小时**。
**瓶颈根本不在查询速度，在我把调度频率设低了。**

## 新默认值：10 分钟一轮 × 400 个

    400 个 × 0.65 秒 ≈ 4.4 分钟/轮
    10 分钟一轮 → 2,400 个/小时 → 7,784 个约 **3.2 小时**

## ⚠️ 为什么不是更激进

查调度器源码发现一条**架构约束**（`run_due_jobs` 的注释写明）：

    作业串行执行 —— 目前只有 CK 巡检，单轮约 20~40 秒，远小于 tick

也就是**我的作业跑着的时候，CK 巡检/重登都得等着**（tick 5 分钟）。
所以一轮时长必须**明显小于间隔** —— 4.4 分钟 / 10 分钟是刻意留的余量。
一轮跑 6.5 分钟以上会把其他自动化作业饿住。

想更快有两条路（都需要你定）：
1. 调大 `batch_size` —— 但**跑得越快越容易被风控**，而风控是全部账号一起受影响
2. 让调度器**并发跑作业**（目前是串行）—— 属另一处改动

## 验证

TZ=Asia/Shanghai **632 passed / 6 skipped**；ruff 全绿。

web/backend/services/automation/__init__.py

@@ -104,10 +104,22 @@ def register_default_jobs() -> None:
         JobSpec(
             key=ACCOUNT_OVERVIEW_REFRESH_KEY,
             title="账号资料定时补全",
-            # 默认每 30 分钟一轮、每轮 30 个 —— 约 20 秒跑完，慢而稳。
-            # 8,000 个待查按这个速度约 3 天补完，全程不打满斗鱼接口。
-            interval_seconds=30 * 60,
-            batch_size=30,
+            # 每 10 分钟一轮、每轮 400 个。
+            #
+            # 依据是**试水实测**，不是拍脑袋：200 个并发 3 跑了 131 秒
+            # = **1.53 个/秒 ≈ 5,500 个/小时**。瓶颈不在查询速度，而在调度频率。
+            # 400 个 × 0.65 秒 ≈ **4.4 分钟**跑完，10 分钟一轮
+            # = **2,400 个/小时**，7,784 个约 **3.2 小时**补完。
+            #
+            # ⚠️ 一轮时长必须**明显小于间隔**：调度器是**串行**的
+            # （见 scheduler.run_due_jobs 的注释：作业一个一个跑），
+            # 我的作业跑着的时候 CK 巡检/重登都得等着。所以宁可轮次多一些，
+            # 也不要一轮跑太久 —— 4.4 分钟 / 10 分钟是刻意留出的余量。
+            #
+            # 想更快就调大 `batch_size`（账号列表里那套），但**跑得越快越容易被风控**，
+            # 而风控是所有账号一起受影响。
+            interval_seconds=10 * 60,
+            batch_size=400,
             concurrency=3,
             run=run_account_overview_refresh,
         )