lovife
9911ff01f1
feat(submit): 提交 + 红黄绿校验（PRD §5.7 的 VAL 系列）
一次给全，不"改一条再拒一次"：学生一次可能同时缺 3 项材料、2 个字段没填，
逐条拒绝会让他改 5 次提交 5 次。所以 validate 收全部问题后一次性返回
{ruleCode, severity, title, detail}，ruleCode 用 PRD 的 VAL-xx 编号。
两段式提交：只有黄色警告时先返回 submitted=false 让学生确认，
再带 confirmWarnings=true 才真的提交。为什么不前端自己判断 ——
只有服务端的校验结果算数，两次请求之间学生可能又改坏了什么。
实现的规则：VAL-01 证件号 / VAL-05 材料完整性 / VAL-06 格式 /
VAL-07 体积 / VAL-08 清晰度 / VAL-09 重复文件 / VAL-13 报考三项 /
VAL-15 补考科目数按等级 / VAL-16 在校生三项 / VAL-17 工作年限 /
VAL-18 未规范化 / VAL-20 体积下限 / VAL-22 表单必填（**新增**：
PRD 的 VAL-01~21 是具体业务规则，没覆盖动态表单的必填字段，按系列顺延补的）。
═══ 本轮抓到的四个真问题（都记在代码注释里了）═══
① **校验器不能用列名当字段 key**。字段 key 是 snake_case
（work_unit / job_level / enroll_date），不是列名；而且报考三项
存在 ext_json 里、**不是独立列**（契约 §2.4）。写 camelCase 的表现是
"明明填了却说没填"。更糟的是 VAL-16 读列、VAL-22 读表单装配值 ——
**两条规则对同一份数据给出相反结论**，学生不知道该信哪一条。
现在统一用 FillService.getForm 装配出来的那一份作为唯一取值口径。
② **VAL-22 没判可见性**。不判可见就会要求一个在校生填「补考理论」——
而那个字段在他页面上根本不存在。求值口径已与前端 fill.vue 的 visible()
逐字对齐（norm 归一 true/false↔1/0、未知 op 一律可见）。
③ **VAL-01 读错了列**：collect_roster.id_card_no 是 **AES 密文**
（列注释写明的），明文只在导入与门禁时短暂存在。一开始拿它算校验位，
于是每一份填报单都被判"身份证号未通过校验" —— 100% 阻断。
这种"规则很对但读错列"的错，反而容易被当成"校验太严"而不是 bug。
现在只确认名册里有证件号（用脱敏列），校验位交给导入与门禁。
④ **静态资源没有 Cache-Control/ETag**（新增 StaticCacheHeaderFilter）。
没有它浏览器会走启发式缓存：旧 index.html → 旧 chunk →
**学生发版后看到的是上个月的页面**，而开发机硬刷新一次就没了，
极容易被当成"偶发"。现在 /assets/** 一年 immutable（文件名带内容哈希）、
*.html no-cache（每次校验）、/api/** no-store。
排查过程里还确认了一件事：材料上传那轮的"浏览器加载旧 chunk"
不是构建问题 —— 从 8080 下载的 chunk 与磁盘文件 SHA-256 一致、里面确实有新代码，
是缓存头缺失导致的浏览器行为。
验收：e2e-m3-submit.py **30/30**（含"该拦的确实拦了"和"修好后确实放过"）。
回归：草稿 27 / 门禁 29 / 材料上传 29 / 材料目录 68 全绿。