yml2213
f0d745ea50
fix(worker-risk): 修掉自动封禁被对账撤销的竞态，以及账号不存在时写假留痕
## 一、刚下的封禁会被对账撤销（生产实测）
Tier 3 是「先把 tracker.banned 置 true，再 await 写库」。在写库提交前的窗口里，
并发的另一个请求会走对账分支、读到 status 仍是 active，于是把刚下的封禁撤销掉。
生产日志（worker 28）：
17:20:11.361 WARN 封禁标记与数据库不一致，已自动解除并放行 ← 对账把刚下的封禁撤了
17:20:11.388 ERROR 打手账号已被系统自动永久封禁！ count=30 ← 27ms 后才写出封禁
后果：刷子能漏进来一个请求；日志还会让运营以为"数据库里已经解封了"。
修法：新增 bannedAt，刚下的封禁在 BAN_GRACE_MS(60s) 内不与数据库对账。
人工解封走 releaseWorkerRiskTracker() 直接删 tracker，不受宽限期影响，处置不会变慢。
## 二、账号不存在时会写下"已永久封禁"的假记录
updateWorkerUser 在账号不存在时返回 null 而**不抛错**，原代码直接把返回值丢弃，
于是照样打出"已被系统自动永久封禁"的日志并写 tier3_autofrozen 留痕。
外挂伪造成随机 uid 时就会命中这条路径，留下一批查不到的假封禁记录。
修法：显式判断返回值，为空则记明确错误并跳过留痕。
## 测试
新增 2 个用例：
- 刚下的封禁在宽限期内不得被对账撤销（锁住上面的竞态）
- 账号不存在时不写"已封禁"的假日志
并更新 2 个原有用例：宽限期内本就不发起对账，原断言（bannedVerifiedAt > 0）已过时。
风控测试 11/11；后端全量 559 测试 556 通过 0 失败。
2026-10-02 17:59:06 +08:00
..
2026-10-02 17:59:06 +08:00
2026-09-19 11:06:32 +08:00
2026-10-02 17:51:39 +08:00