docs(security): protobuf 上界改为实测结论（无人挡住）+ 锁集全量审计数字

[ReSerendipity]

纯文档 PR（只改 docs/SECURITY_DEPENDABOT_TRIAGE.md），但改的是结论，所以带完整判据。

更正了什么

分诊文档 §3a 关于 protobuf 的"被谁挡住"，前两个版本都不成立：

版本	说法	现在的评价
v1	被 descript-audiotools<3.20 / modelscope<3.21 挡住	错：前者不在锁里（开发机多装的）
v2	未证实，等 pip-compile 复算	也不用等 —— 元数据层面就能判定
本版	没有任何包对 protobuf 提无条件约束	实测

方法（不需要下载包，只请求元数据）：读 requirements-lock.txt 的 95 个钉版，逐个
/pypi/<name>/<ver>/json 筛 requires_dist。95 个全部查询成功，提到 protobuf 的 13 行
全部带 extra == 门控：

• modelscope==1.40.1：protobuf<3.21.0,>=3.19.0 只挂在 nlp / all，protobuf（无界）挂在
  audio / audio-tts —— 而 requirements.txt:8 是 modelscope>=1.9.0，一个 extra 都没请求；
• transformers==4.52.1：7 处提到 protobuf，全在 all / dev* / torchhub 等 extra 里；
• sentencepiece==0.2.2：2 处，全在 protobuf / test extra 里；
• funasr==1.4.15：元数据里根本不提 protobuf。

结论：protobuf==3.19.6 不是被钉住的，是这份锁当年编译留下的历史值。#90（→ 7.36.1）
在元数据层面可解，且其实不必跳那么大 —— 4.25.8 关 P1、5.29.6 关 P2（同一公告另有
6.31.1 / 6.33.5 两条并行修复线）。

为什么仍然不合 #90

风险不在元数据里，在运行时：protobuf 跨大版本最常坏在 gencode 与运行时不匹配
（旧 _pb2.py 在新运行时 import 期即报 Descriptors cannot be created directly），而这条只有
真装环境 + 真加载模型才走得到。本仓 app/ 对 google.protobuf / _pb2 零直接引用，
CI 上跑绿的 12 个 pytest 矩阵是无 GPU 的 CPU 环境 —— 绿不构成证据。所以处置改成
"排在复算 + 真机复验之后批量抬"，并把命令写清（§7b），GB 级传输留给所有者跑。

新增 §7

• 7a 全锁审计（OSV querybatch，95 个包一次问完）：只有 2 个包有公告 ——
  transformers==4.52.1 24 条记录 = 16 个去重公告（§1 A1–A16）、protobuf==3.19.6
  4 条记录 = 2 个公告（P1/P2），其余 93 个包 0 公告。整份锁的已知漏洞面集中在这两个包上，
  且都已登记完。附可复现脚本。
• 7b 复算 + 真装验收的命令清单（新建 .venv-relock，不动现有 .venv 与 model/），
  含三个必须在复算里回答的问题、以及三引擎的真机基线数字（214,040 B / RMS 6176 等）。

验证

本机：pytest tests/test_dependency_consistency.py 11 passed（§1 表被 D4 解析，改行没破坏
"豁免集合 == 表集合"这条断言）、check_spec_refs.py new=0、ruff check / format --check 全绿。
工作树只含这一个文件（临时脚本已删）。