docs: 清掉三处"会静默过期"的小账 + check-test-profile 加固（F-98）

一、附录 A 从"手抄表"改成"可再生成的命令"
   check-api-parity.py 加 --extra，现算"代码有、契约 §4 没有"的接口 = 41 个
   （旧手抄表写 83/62/21，已差近一倍，而且没人会记得回来改它）。
   并按"谁去改什么"分六类 —— 只有 E 类（8 个）要客户定口径，其余是文档侧补记。

二、F-6 已修：frontend-pc 的 Mock 说明
   AGENTS.md 那句改正之外，连带修了 .agents/skills/project-api/SKILL.md ——
   它整篇仍以 vite-plugin-mock / mock/** 为主线，而该项目里 mock/ 目录与插件都已删除。
   只改指路牌、不改路的尽头，等于没改。

三、docs/03 两处文档内部口径冲突加 ⚠️ 注（不改口径，只把冲突摆明）
   §2 notifyBizType 的 5/6 与 §13.5、落库值不一致 → 实现以 §13.5 为准（催报去重按 5）；
   §3.6/§9.5 的 collect_file.source 字段表（入口来源）与建表注释（谁传的）冲突 →
   实现以建表口径为准。两处都写明"待客户确认"，见 F-30 / F-38 / F-39。

四、check-test-profile.py 加固（新增 F-98）
   · 子进程输出落盘（不再用没人读的 PIPE）：失败时能看见"停在哪一行"，
     成功时打出启动用时（基线 ~10 秒 / 72 行 / 9.5KB）；
   · 开跑前按 jar + profile 清残留 JVM，且保留 dev 后端（E2E 正打着它）；
   · 等待期间每 15 秒报一次进度，卡住时不留沉默。
   教训：随机端口这个防撞设计把残留 JVM 藏起来了 —— 撞不到端口就永远发现不了，
   于是表现成"时好时坏"，而失败时连日志都读不到。

验证：python scripts/verify-all.py --with-e2e → 通过 8 / 失败 0 / 跳过 0
      （E2E 36 脚本 / 1548 断言 / 278s；prodguard 9/9；test profile 能起）
      python scripts/verify-docs.py → 22 项全部通过

docs/03-接口设计.md

@@ -256,11 +256,22 @@
 | `detectSource` | `1` 文件名 / `2` 形态 / `3` OCR 内容 / `4` VLM / `5` 用户指定 |
 | `compressProfile` | `P1` 证件照 / `P2` 证件翻拍 / `P3` A4 扫描件 / `P4` 截图 / `P5` 兜底 |
 | `notifyChannel` | `1` 微信订阅消息 / `2` 短信 / `3` 公众号模板 |
-| `notifyBizType` | `1` 任务发布 / `2` 临期提醒 / `3` 驳回通知 / `4` 审核通过 / `5` 导出完成 / `6` 催报 / `7` 加入名单审批 |
+| `notifyBizType` | `1` 任务发布 / `2` 临期提醒 / `3` 驳回通知 / `4` 审核通过 / `5` 导出完成 / `6` 催报 / `7` 加入名单审批 ⚠️ 见下方注 |
 | `exportStatus` | `0` 排队中 / `1` 打包中 / `2` 已完成 / `3` 失败 / `4` 已过期 |
 | `cleanupSourceType` | `1` 压缩包 / `2` 文件夹 / `3` 云盘链接 |
 | `cleanupStatus` | `0` 排队 / `1` 解析中 / `2` 处理中 / `3` 已完成 / `4` 失败 |
 
+> ⚠️ **`notifyBizType` 的 `5` / `6` 在本文件内部是不一致的**：本表写「`5` 导出完成 / `6` 催报」，
+> 而 §13.5 消息中心的示例（`2` 临期提醒 / `3` 驳回）与落库值 `collect_notify_record.biz_type`
+> 用的是「**`5` 催报 / `6` 导出完成**」。
+>
+> **实现以 §13.5 为准**（代码里是 `CollectMessage.BIZ_URGE = 5` / `BIZ_EXPORT = 6`，
+> 催报去重按 `5` 走）。这不是文案问题：若按本表实现，催报会被写成"导出完成"，
+> **去重会静默失效**（老师点两下学生收到两条），而排查时从数据上完全看不出是码对不上。
+>
+> 需要客户确认以哪一边为准；若确认以本表为准，要一起改的是两个常量 + 已落库的历史数据。
+> 记录见《08-完成度盘点与问题清单》**F-30**。
+
 ---
 
 ## §3 通用数据结构
@@ -461,9 +472,19 @@
 | `vlmCalled` | bool | `vlm_called` | 是否调用过 VLM（**成本监控用**） |
 | `validateStatus` | int | `validate_status` | 见 §2.7 `fileValidateStatus` |
 | `issues` | array | — | 该文件的 `ValidationIssueVO[]` |
-| `source` | int | `source` | `1` 聊天记录 / `2` 相册 / `3` 手机文件 / `4` 代传 |
+| `source` | int | `source` | `1` 聊天记录 / `2` 相册 / `3` 手机文件 / `4` 代传 ⚠️ 见下方注 |
 | `rawExpireTime` | string | `raw_expire_time` | **原图过期时间（默认 30 天）** |
 
+> ⚠️ **`collect_file.source` 有两套互相冲突的口径**：本表写的是"从哪个入口选的"
+> （`1` 聊天记录 / `2` 相册 / `3` 手机文件 / `4` 代传），而建表注释（`V1__business_tables.sql`）
+> 与实现（`CollectFile.SOURCE_*`）写的是"**谁传的**"：
+> `1` 本人上传 / `2` 班主任代传 / `3` 管理员代传 / `4` 整理器导入。
+>
+> **实现以建表注释为准**：§10.6 要求代传必须可追溯，要回答的是"**谁**替他传的、
+> **为什么**"，而不是"他从哪个入口选的"—— 后者在同一个学生身上还会随操作路径变化。
+> 两个口径都是 4 个值、含义完全不同，所以"照字段表写"会得到一份**看起来有数据、
+> 但答案是错的**统计。记录见《08-完成度盘点与问题清单》**F-38 / F-39**。
+
 **`ownership.verdict` 取值**（对应 PRD §6.1 归属裁决矩阵）
 
 | verdict | 含义 | blockSubmit | 学生端表现 |
@@ -1784,7 +1805,7 @@ Excel 列：`层级` `组织名称` `组织编码` `上级编码` `负责人手
 | `fileName` | string | ✅ | 原始文件名（**可能是乱的，正常**） |
 | `fileSize` | int64 | ✅ | 字节 |
 | `contentType` | string | ✅ | MIME |
-| `source` | int | — | `1` 聊天记录 / `2` 相册 / `3` 手机文件 |
+| `source` | int | — | `1` 聊天记录 / `2` 相册 / `3` 手机文件（⚠️ 落库口径见 §3.6 注：实际存的是「谁传的」= 1 本人上传 / 2 班主任代传 / 3 管理员代传 / 4 整理器导入） |
 | `fileHash` | string | — | 客户端 SHA-256（**用于秒传与去重**） |
 
 **响应**
@@ -2862,6 +2883,7 @@ X-Sign: HMAC-SHA256(appSecret, appKey + timestamp + nonce + body)
 
 | 版本 | 日期 | 变更 |
 |---|---|---|
+| **V2.5** | **2026-09-30** | **两处"文档内部口径冲突"加注（不改口径，只把冲突摆到明处）**：① §2 枚举 `notifyBizType` 的 `5`/`6`（本文件写「5 导出完成 / 6 催报」）与 §13.5 消息中心示例、落库值 `collect_notify_record.biz_type`（「**5 催报 / 6 导出完成**」）不一致 —— **实现以 §13.5 为准**，需要客户确认以哪边为准（若以 §2 为准，要同时改两个常量与已落库数据）；② §3.6 与 §9.5 的 `collect_file.source` 字段表写的是"入口来源"（1 聊天记录 / 2 相册 / 3 手机文件 / 4 代传），而建表注释与实现（`CollectFile.SOURCE_*`）是"**谁传的**"（1 本人上传 / 2 班主任代传 / 3 管理员代传 / 4 整理器导入）—— **实现以建表口径为准**（§10.6 要求代传可追溯，要回答的是"谁替他传的"）。两处均已在原文加 ⚠️ 注。记录见《08-完成度盘点与问题清单》**F-30 / F-38 / F-39**。 |
 | **V2.4** | **2026-09-28** | **修正 3 处加密列宽不足（DDL 缺陷）**：`sys_tenant.contact_phone`、`sys_user.phone`、`collect_roster.phone` 原为 `varchar(20)`，是按**明文手机号**的长度建的；但 PRD §10.3 要求手机号 AES-256 加密存储，AES-GCM 密文约 **52 字符**，插入会直接报 `value too long for type character varying(20)`。（`id_card_no` 当初给了 `varchar(128)` 就是考虑到了加密，手机号三列漏了——属设计不一致。）三列统一改为 **`varchar(128)`**，与 `id_card_no` 对齐。**发现方式**：M0 开通租户实测时数据库报错暴露。**审计结论**：其余 `*_mask varchar(32)` 列存的是脱敏值（如 `138****8888`）而非密文，宽度足够，无需改动。 |
 | **V1.2** | **2026-09-28** | **错误码规范化**：`40007b` / `40007c` 带字母后缀，与 §1.3「`code` 为数字」的约定冲突（JSON 里会变成字符串，前端 `code === 0` 判断失效）。改为纯数字：**`40007b` → `40071`**（门禁限流）、**`40007c` → `40072`**（名单项已被绑定）。总码数不变，仍 **58 个**。 |
 | V1.0 | 2026-09-28 | 首版。PRD §8 的 96 个接口全部展开字段级定义；**补齐追溯矩阵审计发现的 10 个缺口（新增 21 个接口，含 1 个登记遗漏）**；错误码由 20 个扩至 **50 个**；新增 §2 枚举全集、§3 通用数据结构、§15 错误码全集 |