docs(25): 撤回一条误报——ai_analysis 的并发控制一直存在

复核 P1 #5 时发现 .with_for_update() 就在 
isk_analysis_service.py:121-125，
而初次报告只读到 :130-160、恰好漏看了锁所在的那几行，却把这条标成了"✅ 已验证"。

实测推翻（并发发起三种分析，各自独立 session —— 复用同一个 session 会天然串行、
测不出竞争）：
- 预警研判 1809 字 / 回访话术 2030 字 / 工单摘要 1088 字，三个请求全部成功
- 落库 ai_analysis 的键：['回访话术', '工单摘要', '预警研判'] —— **三个都在，未发生覆盖**

所以 P1 #5 只剩前半条（审计不经基座统一链路）仍然成立，并发那条撤回。

教训一并写进文档：标注"已验证"之前必须确认自己真的读到了关键那段代码，
否则标注本身就是误导 —— 这与 _topic_of 那几轮踩的是同一个坑。

docs/25-风控模块代码评审报告.md

@@ -99,8 +99,17 @@ agent_intent_config 中 agent_type='risk'：0 条
 真正的问题是两条：
 
 1. 审计**不经基座统一链路**（只有走 `call_tool` 才有 `_tool_records` 与统一审计）；
-2. `ai_analysis` 是**读-改-写且无并发控制**（`dict(alert.ai_analysis or {})` → 赋值 → commit），
-   并发请求会互相覆盖。
+2. ~~`ai_analysis` 是**读-改-写且无并发控制**，并发请求会互相覆盖。~~
+
+   **本条经复核为误报，已撤回（2026-09-11）。** 证据：`risk_analysis_service.py:121-125`
+   的查询上**一直有** `.with_for_update()`，读-改-写（`:138-145`）整体在行锁内、到 `:156`
+   才提交。实测并发发起三种分析（预警研判 / 回访话术 / 工单摘要，各自独立 session、
+   复用同一 session 会天然串行测不出竞争），落库的 `ai_analysis` **三个键全部保留**，
+   未发生覆盖。
+
+   初次报告把它写成缺陷，原因是我只读到 `:130-160` 这一段、**恰好漏看了锁所在的
+   `:121-125`**，却把这一条标成了"✅ 已验证"。教训与前面 `_topic_of` 那几轮相同：
+   **标注"已验证"之前必须确认自己真的读到了关键那段代码**，否则标注本身就是误导。
 
 ### 6. 时区口径不统一 🔁 ✅（最严重的业务缺陷）