feat(notify): 通知接线检查 + 修 F-101~F-111（模板对自动通知生效 / 催报真的会发 / 该发的通知都发了）

起点：F-1/F-31/F-50/F-52 是同一个形状 —— 每处单看都对，编译/lint/review 全不红，只有从入口走一遍才暴露。先把这一类固化成命令，再按输出逐条修。

新增 scripts/check-wiring.py：权限码有没有地方校验、错误码有没有被引用、站内信模板有没有发送点、bizType 有没有被用过、菜单键 ↔ PC 端 XtMenu 双向核对。有意不接线的写进脚本上方例外表（带理由）。进 verify-all（第 5 项）与 CI 的 check 阶段。检查器自身修了三次假阳性：只数 @RequirePerm 漏掉服务层校验、按标识符数引用被同名常量骗过、注释里的提及被当成接线（改为先去 Java 注释再数）。

F-101 自动通知改走可配置模板（FR-1002 原来只兑现了手工发送那一半）：新增 NotifyTextResolver（单向依赖避开循环注入），库里改过的 > 内置；模板停用 = 这类通知不发且如实回 notifySent=false。F-102 加入申请三处通知（提交→审批人、通过/驳回→学生）。F-103 导出完成/失败通知发起人，正文不放签名 URL（模板里原本写着 {下载链接}，一并改掉）。F-104 自动催报从来没发出过任何一条（end_time = date::date 与库里的 23:59:59 永不相等，测试夹具用 SQL 摆的日期型恰好能匹配）+ 补 FR-1003 的「截止当日」。F-105 驳回达上限通知管理员（契约与注释都写了，代码只有一行日志）。F-106 字典/通知记录两个菜单没有任何角色持有（手册还写着去那里办）。F-107 6 个权限码挂到自己的接口。F-109 Map.of 不接受 null → 通知被吞成一行 warn。F-110/F-111 测试自身的两个坑。

验证：新增 e2e-m5-notify-wiring.py 43 条（改模板→真驳回→断言学生收到改过的那句、停用→一条不发、申请/审批/导出/催报/升级/菜单/权限各一节）；verify-all --with-e2e → 9 项全过 0 跳过，38 个脚本 / 1620 条断言 / 0 失败。

.gitlab-ci.yml

@@ -2,8 +2,8 @@
 #  GitLab CI（M0-04 / M7-10）
 #
 #  设计原则：**流水线跑的必须是我们真正依赖的那套验证**。
-#  这个仓库没有单元测试（`src/test` 是空的），验证靠三样东西：
-#    ① 三个机械校验脚本（契约对账 / 实体列 / 文档一致性）
+#  这个仓库的单元测试很少（`src/test` 只有 12 条纯函数），验证靠三样东西：
+#    ① 五个机械校验脚本（契约对账 / 实体列 / 文档一致性 / 手册文案 / **接线**）
 #    ② 编译与构建（后端 jar、PC、H5）
 #    ③ **`scripts/e2e-*.py` 打真实接口 + 查库断言**（1500+ 条）
 #  所以 e2e 阶段不是"锦上添花"，它是这个项目的主验证手段 ——
@@ -58,6 +58,8 @@ variables:
     - python scripts/verify-docs.py
     - echo "── 手册里引用的错误码与文案是否真的存在（客服照着它回答） ──"
     - python scripts/check-manual.py
+    - echo "── 声明了但没接上的东西（权限码 / 错误码 / 通知模板 / 菜单键） ──"
+    - python scripts/check-wiring.py --quiet
     - echo "── 全部 e2e 脚本的语法（引号写错会当场红，而不是跑到一半才红） ──"
     - |
       python - <<'PY'