docs(plan): P1b 小规模实测完成——20/20 全部重登成功

按 §7.4.7 第一段跑实测，用现有手动重登链路（batch 65eda0142b4c）对 20 个
invalid 账号重登，两组各 10：A「还没在 attempt_* 时代重试过」、B「取码 bug
时代失败过」。

结果：
- 成功率 20/20 = 100%（历史推断只有 78%）；耗时 2 分 13 秒（约 9 个/分钟）；
- 极验滑块 0 次；邮箱取码全部正常 —— B 组全过，证实那 144 条「验证码失败」
  确实是 20261001 修掉的取码 bug 造成的，修复在生产生效；
- 20 个 CK 全部替换成功，ck_check_status 由登录流程自动改回 valid。

可救量由此从估的 1,050 上调到约 1,350；失败分型仍要做但属少数路径。
实测速度与零极验说明当前风控容忍度比预想高，全量仍建议限速（每小时
100~200 个起步，观察极验率再决定是否加速）。

docs/自动化与资料收集规划.md

@@ -534,9 +534,21 @@ lookup_order(order_no) -> {
 
 #### 7.4.7 上线方式（三段，同 P1a 的谨慎程度）
 
-1. **小规模实测**：挑 10~20 个 invalid（覆盖「未重试过」与「取码 bug 时代失败过」两类），
-   用现有手动重登链路跑一次 —— 把「78% 成功率」从历史推断变成实测，同时验证
-   `20261001` 的取码修复在生产真的生效；
+1. **小规模实测** ✅ **已完成（2026-10-02），结果远好于预期**：
+
+   | 项 | 结果 |
+   | --- | --- |
+   | 样本 | **20 个** invalid，两组各 10：A「还没重试过」/ B「取码 bug 时代失败过」 |
+   | 成功率 | **20 / 20 = 100%**（历史推断只有 78%） |
+   | 耗时 | 2 分 13 秒（≈ 9 个/分钟） |
+   | 极验滑块 | **0 次** |
+   | 邮箱取码 | 全部正常 → **`20261001` 的取码修复在生产验证通过**（B 组全过，证实那 144 个「验证码失败」就是旧 bug 造成的） |
+   | CK 替换 | 20 个全部换成新 CK；`ck_check_status` 由登录流程自动改回 `valid`（`login_service.py` 成功分支） |
+
+   **结论**：会话确实只是过期，重登几乎必定成功；可救量从估的 1,050 上调到
+   **≈1,350**（1,356 × 近 100%）。失败分型仍然要做，但属少数路径（极验/配额/凭证）。
+   实测 9 个/分钟且零极验，说明斗鱼当前风控容忍度比预想高，不过全量仍建议限速
+   （先按每小时 100~200 个开，观察极验率再决定是否加速）；
 2. **限量开作业**：按实测成功率定 `batch_size` 与日上限，先只跑一个分组；
 3. **全量**：观察若干轮，确认分型与退避符合预期后再放开。