fix(ci): strict preflight refuses an APPROVE body that names no full head SHA

[jhfnetboy]

Follow-up to #452 requested by DSR (CC-124 comment 902e531e).

问题：在严格模式下，如果 APPROVE 的正文里没有任何完整 SHA，脚本只打印 WARN，然后退回到用 commit 时间戳判断，最终退出码仍是 0。而时间戳可以被伪造的 committer date 静默绕过。所以 #452 之后，每次合并仍要额外人工确认「正文里写的是完整 head」。

修复：严格模式下，最新一个 APPROVE 的正文必须写出完整的 40 位 head SHA，否则 FAIL。--ci 模式保持 WARN，因为它只是报告，并且每次刚 approve 时都会处于这个状态。

测试：夹具新增 4 个场景，共 52 个。

场景	本 PR	origin/main
正文没有 SHA	FAIL	exit 0（放行）
只写了 8 位缩写	FAIL	exit 0（放行）
写的是另一个完整 SHA	FAIL	FAIL
写的是完整 head（对照）	PASS	PASS

本 head 52/52；origin/main 50/52，没对上的正好是两个新的放行场景。

影响：只影响严格模式下的这一项检查。#446 本来就因为「正文写的是另一个完整 SHA」而 FAIL，结论不变。

head：8dbbadb4d35bfa543e429bd3d6e84742d9bebe37

🤖 Generated with Claude Code

https://claude.ai/code/session_0177oe2fF7ywx8M9VSKcEbij

[clestons]

APPROVE — #457（head 8dbbadb4d35bfa543e429bd3d6e84742d9bebe37）

意图：DSR CC-124 对 #452 的跟进——严格模式下，APPROVE 正文没有写完整 40 位 head SHA 时只 WARN、退出码仍是 0，靠回退到 commit 时间戳判断，而时间戳可被伪造的 committer date 静默绕过。本 PR 让严格模式在这种情况下直接 FAIL；--ci 模式保持 WARN（因为它只是报告，不是门禁，且每次刚 approve 都处于这个状态）。

亲自验证

• 读了 merge-preflight.sh 的全局结构：fail=0 初始化（:58），exit "$fail"（:558）是唯一出口；本 PR 新增的 else 分支在非 CI_MODE 下执行 fail=1，和脚本里其余处理同类问题的既有写法（如 :327 [ "$CI_MODE" -eq 1 ] || fail=1）完全一致的模式，确认会真实传导到脚本最终退出码。
• 亲自跑了 scripts/test_merge_preflight_strict.py：52/52 通过，与 PR 自称一致。四个新场景逐一核对：无 SHA → FAIL；只写 8 位缩写 → FAIL；写的是另一个完整 SHA → FAIL（且断言了具体报出的是哪个错误 SHA）；写的是完整 head（对照组）→ PASS。
• test_merge_preflight_strict.py 自身的改动（给 sc() 加一个可选 extra 参数）是向后兼容的扫描——默认 None，旧场景不受影响，只有新增的 4 条场景传了这个参数去额外断言 FAIL/OK 那一行的具体文案。

R1a

0 findings。GATE 全 NO（不涉及并发/安全面/隐藏状态），TRIAGE 标"significant"是因为这改变了合并门禁从 WARN 到 FAIL 的行为，但这正是本 PR 的明确目的，不是意外副作用。

pre-pr-check

0 block / 1 review（B1，merge-preflight.sh:211 的断言性注释——PR 的 diff 本身就是那条注释对应的代码，commit message 和注释逐字对应，不阻塞）。

结论

APPROVE。门禁行为变更（WARN→FAIL）经真实测试套件验证（52/52，含 4 个新场景的精确断言），退出码传导路径亲自读代码确认正确。

本评审只给结论，不做合并。