fix(huya): 修复外部单积分复核与抢购结果误判

docs/设计-虎牙外部CK协作台账.md

@@ -272,6 +272,10 @@ incomplete ─资料齐全且 CK 有效─▶ to_recharge ─充值核账─▶
 - `必充积分 = Σ required_points`；`结余 = 账号积分合计 - 必充积分`；
 - `结余 < 0` → 整组 `points_error`（`reason=shortage`）；
   `结余 > 阈值` → 整组 `points_error`（`reason=excess`）；其余 → 整组 `recharged`；
+- 首次算出异常**不立即落库**：同批异常组统一等待 30 秒后再查一次积分，
+  第二次结果才决定 `recharged / points_error`。这用于兜住积分接口缓存或到账延迟，
+  避免瞬时 `0` 分被误判；两轮积分都会写生命周期快照（第二轮 `source=recharge_retry`），
+  `points_check_detail.confirmation` 保留第一轮余额、结余和实际等待时间；
 - 阈值默认 `100`，前端可改并记忆；范围 `0..1_000_000`；
 - CK 失效 / 积分查询失败 / 缺少 `required_points` 时**整组保持原状态**并逐组报错；
 - 每个组内订单都写同一份快照：`points_checked_at / points_balance /
@@ -463,8 +467,9 @@ unverified ──探针成功──▶ valid ──探针失败──▶ invalid
 
 | 情况 | verdict | 业务状态 |
 | --- | --- | --- |
-| 兑换记录里有这一单的礼包（名字互相包含即算命中，`gift_matches_records()`） | `success` | 「已上脚本」→ 自动「抢购成功」`done` |
-| 接口通了，但记录里没有这个礼包 | `failed` | 「已上脚本」→ 自动「抢购失败」`failed` |
+| 兑换记录里有这一单的礼包（名字互相包含、且兑换时间不早于上脚本时间） | `success` | 「已上脚本 / 抢购失败」→ 自动「抢购成功」`done` |
+| 接口通了，但记录里没有这个礼包，且已超过上脚本后的 10 分钟确认窗口 | `failed` | 「已上脚本」→ 自动「抢购失败」`failed` |
+| 接口通了，但仍在确认窗口内没查到 | `unknown` | **不动**；官方记录有落库延迟，暂不作为失败结论 |
 | 接口没通 / 这单没填礼包名 | `unknown` | **不动**（数据不够，不许瞎判） |
 
 **四条边界**：
@@ -472,9 +477,9 @@ unverified ──探针成功──▶ valid ──探针失败──▶ invalid
 1. **只手动触发**：单行「查积分 / 兑换记录」+ 勾选批量查询（串行 + `PROBE_BATCH_INTERVAL_SECONDS`
    间隔，上限 `PROBE_BATCH_MAX=50`）；**不做定时轮询** —— 虎牙风控（§12），
    而且"什么时候去查"本身是运营的判断（抢购是人工触发的）；
-2. **只有 `scripted` 的单会自动改状态**：抢购发生在上脚本之后，
-   别的阶段查到什么都说明不了问题；这种情况 metric 照写，结论里写明
-   "只有「已上脚本」的单才会按查询结果自动改状态"，由人决定要不要手动切；
+2. **自动判失败只作用于 `scripted`**，且必须过了上脚本后的 10 分钟确认窗口；
+   没查到时窗口内一律 `unknown`。已经落到 `failed` 的单后续如果查到匹配记录，
+   允许自动纠正为 `done`（审计按回退恢复留痕）；其它阶段 metric 照写但不自动改；
 3. **接口失败也写快照**（verdict=`unknown`）：失败本身也是"这一刻的状态"，
    下次查到成功就能在时间线上看出"积分从 X 涨到 Y"，这正是要的证据；
 4. **`void` 的单不查**、没 CK 的单不查（`void_order` / `no_cookie`，400），
@@ -483,6 +488,8 @@ unverified ──探针成功──▶ valid ──探针失败──▶ invalid
 
 礼包匹配用**互相包含**（`prize_name` 与 `order.gift_name` 双向包含即命中），
 但名字短于 2 个字（`_MIN_GIFT_MATCH_LENGTH`）不参与 —— 免得"礼包"两个字匹配一堆记录。
+记录带 `exchange_time` 时还必须不早于 `scripted_at`（秒级比较），防止同一买家重复买同款时
+把上一次兑换误当成这一次成功。
 
 ---
 
@@ -1107,7 +1114,7 @@ unverified ──探针成功──▶ valid ──探针失败──▶ invalid
 | 探针接口被风控 | 只做人工触发、串行、带间隔；不做定时轮询 |
 | CK 被导出后外传（导出到剪贴板 = 凭据出门） | 单行复制与批量导出统一走 `huya:collab:ck_export`（默认运营和客服可用，权限页可覆盖）+ 逐行审计（不含 CK 本体）+ 界面常驻警告；明文只在弹窗 state 里，关掉即清（§11.8） |
 | 积分 / 兑换记录查询被风控 | 同上：只手动触发（单行 + 勾选批量，串行带间隔），不做定时轮询（§5.7） |
-| 自动改状态误判（接口抖动 → 判成"抢购失败"） | 三态判定：取不到数据一律 `unknown` 且不动状态；只有 `scripted` 的单才自动改；每次查询留快照，人工可回退（`rollback`） |
+| 自动改状态误判（接口抖动 / 兑换记录延迟 → 判成"抢购失败"） | 三态判定：取不到或在 10 分钟确认窗口内没查到的都保持 `unknown`；只有过了窗口的 `scripted` 单才自动判失败；之后查到匹配记录可自动纠正为 `done`，每次查询留快照 |
 | 积分中心 `queryAllocation` 拉不到 / 返回空 → 礼包列表空白 | 只影响「拉礼包」，不影响 CK 有效性；提示用户稍后点「强制刷新礼包」。旧 `getActPrizeList` 的 SID 过期问题只保留给精英宝典工作台（§11.4） |
 | 自由文本的"绑定斗鱼号"没法校验 | 先按文本存（Excel 里就是文本）；能拿到结构化 uid 时补 `bind_douyu_uid` |
 | 图片越攒越多 | §6.4 孤儿清理脚本 + `file_assets` 台账已有 `size_bytes` 可统计 |