docs(security): 救回 CodeQL 分诊台账并按 09-21 实测刷新（open 110→76，critical 归零）

[ReSerendipity]

为什么单开一条

PR #81 的主体方向（"两个 lock 钉的 transformers 4.52.1 低于自家下界 4.57，要抬下界"）被实测推翻：
真正写错的是下界本身，实测能跑的就是 4.52.1（indextts 2.0.0 钉 transformers==4.52.1），
已按 #103 回退并在 docs/SECURITY_DEPENDABOT_TRIAGE.md §1a 记下我当时的方向错误。

但 #81 里还带着一份逐条读过代码的 CodeQL 存量告警分诊表（181 行：110 条告警按规则/落点分布、
5 个族已定性、4 个族标明"未审（不假装看过）"、分批处置建议、以及 §5 的 dismiss 执行记录）。
这是本仓唯一成体系的 CodeQL 台账 —— 跟着 PR 一起关掉就没了，而仓库现在有 76 条 open 告警需要它。

所以：救文档，不救方向。§0–§5 原文一字未改（那是 2026-09-20 的定性快照），新增 §6 记录今天的重测。

§6 刷新了什么（全部是实测，不是推算）

	09-20（§0）	09-21 实测
open	110	76
high / medium / critical	72 / 37 / 1	46 / 30 / 0

34 条差额逐条对上账：§5 已记的 25 条 dismiss + §5 之后又 dismiss 的 7 条
（js/xss-through-dom #95–#99/#105/#106，09-20 16:07 一批，理由与插值来源都在平台 comment 里）

• 重扫自动转 fixed 的 2 条。守恒：110 open + 2 fixed = 76 + 32 + 4 = 112，窗口内没有新增。
  那 7 条 §5 没记（它冻结在 00:28）—— 记为台账滞后，不是处置缺理由。

两处按代码复核（不是按文档相信文档）：

• §2.1 声称的 critical 处置确在 main：persona_manager.py:436-440 的 realpath 前缀守卫、
  _PERSONA_NAME_RE.fullmatch（已从 match 改掉）、tests/test_persona_embedding_load.py 在库。
• §6.3 记下两条与本文档旧表述不一致的事实：
  ① CSRF 那条落地时没有 TTS_ALLOW_EPHEMERAL_CSRF 这个环境变量开关（fix(security): CSRF 密钥不可用时拒绝启动（清单已重生成并重签，可正常合并） #109 走的是"任何取不到都拒绝启动"），
  照 §4 那行去找这个开关会找不到；
  ② 告警 chore: add cleanup report and non-destructive removal scripts (bot/cleanup-ignored-files-2026-08-06) #1 因为写入位置从 :816 移到 :745，在 fix(security): CSRF 密钥不可用时拒绝启动（清单已重生成并重签，可正常合并） #109 的 PR 差异里被算成 "1 new alert"。

门禁口径没变，所以这张表才会漂走

main 的必需检查仍只有 ruff / pytest(3.12,ubuntu) / mypy ratchet，strict=false，CodeQL 不在其中。
§4 那行"CodeQL 是否进必需检查"的决策仍未定，判据不变：先降到 <30 再纳入（现在 76）。

验证

scripts/check_spec_refs.py → new=0（本文档没有引入悬空引用）；
verify_cloud_native.py 全绿；纯文档改动，不涉及运行时代码与签名清单。

Refs: #81（被本条接替其文档部分）、#103（下界回退）、#109（CSRF 硬失败 + 0600）