[自动合并 P1-4] drift-check：required check 活体验证 + PR liveness 侦测

[randypanding]

目标

给 drift-check 增加两类"活体验证"：(a) required check 活体存在性——ruleset 文本正确但实际匹配为空时检出；(b) PR liveness 侦测——auto-merge 已开但卡死的 PR 自动开 issue。

背景（源自 #81 §3.2 / §6）

• required check 是字符串精确匹配。gate 是唯一 required check，一旦 job 改名或 workflow 重构，ruleset 静默匹配不到任何东西 → 变成"零 required check" → PR 裸奔合并。而 drift-check 现在只对账 ruleset JSON 文本，JSON 完全正确的同时实际匹配为空。文本对账 ≠ 生效验证。
• 门禁再严，如果每周有五个 PR 卡住等人手动捞，人还是瓶颈。drift-check 现在只看治理漂移，不看"流水线卡死"。需要：auto-merge 已开但 >N 小时未合并 / check pending 超时 / 应有而无 check run → 自动开 issue。

涉及文件

• governance/drift-check.sh（新增两个检查段）
• governance/expected-state.json（声明 liveness 阈值，如 pr_liveness_hours: 4）
• .github/workflows/governance-drift.yml（如需新权限：读 PR/check runs——actions:read、pull-requests:read、checks:read）

执行步骤

1. 活体验证段：对每个受管仓，拉最近 N 个（建议 20）已合并/打开的 PR 的 check runs（gh api repos/.../commits/{sha}/check-runs），断言存在名为 gate 的 check run 且 conclusion 非空。若最近没有 PR 活动，退化为对默认分支 HEAD commit 断言 check run 存在。
2. PR liveness 段：遍历受管仓所有 open PR，检出三类卡死：
   • auto_merge 已设置但 PR open 时间 > 阈值；
   • 任一 required check pending/queued 超过阈值；
   • PR HEAD 上完全没有任何 check run（应有而无）。
     命中即开 issue（打 drift label，复用 GM-1 通道），恢复后自动关闭。
3. 阈值进 expected-state.json，可被对账。
4. 权限评估：governance-drift workflow 用的 token 需能读各仓 check runs/PR，按最小权限补齐。

验收标准

• 把某测试仓 gate job 改名后，drift-check 下一次运行即报"required check 活体缺失"并开 issue；改回后 issue 自动关闭。
• 构造卡死 PR（阈值临时调低）后，drift-check 开出指明该 PR 的 liveness issue。
• 正常状态下不误报（连续 3 天运行无假 issue）。

测试方法（预先指定）

T1 required-check 活体缺失注入（核心，负向）

1. 在测试仓 Use-up-Plan 的 PR 里把 workflow 中 job 名从 gate 改为 gate2（ruleset 仍要求 gate）。
2. 手动触发 governance-drift workflow。
3. 断言：workflow 检出 Use-up-Plan 的 required check 活体缺失并开 issue，issue 内容指明"ruleset 要求 gate 但实际 check runs 中无此名称"。
4. 还原 job 名，再触发，断言 issue 自动关闭。

T2 PR liveness 注入（负向）

1. 把 liveness 阈值临时改为 1 分钟（通过 expected-state.json 临时值或 workflow dispatch input 注入）。
2. 在测试仓开一个 PR 并 enable auto-merge，但让其 check 永不完成（例如 push 一个含 if: false 使 gate 不产生的分支——产生"应有而无 check run"型卡死）。
3. 触发 drift-check，断言：开出 liveness issue，内容含 PR 链接与卡死类型。
4. 关闭测试 PR、还原阈值，断言 issue 关闭。

T3 误报控制（正向 soak）

• 合入后连续观察 3 天（drift-check 每小时跑）：断言无一条 liveness/活体误报 issue。出现误报先修判定逻辑，不允许调大阈值掩盖。

依赖

• P1-1（drift-check 已覆盖 repo settings，本卡在其框架内扩展）

[randypanding]

P1-4 完成核验（2026-08-20，randypanding 授权 agent 执行；实现=PR #108/#109/#111/#120 多轮协作）：

T1 required-check 活体缺失注入（核心负向） ✅：

• agent-tools 注入 3 个 gate→gate2 改名 PR（docs: 测试政策决策记录 #4/refactor: 政策声明式重构 + 治理总声明 GOVERNANCE.yaml #5/feat: agent 声明标准与 agent_runtime 治理域 #6，被 ruleset 阻塞不会误合）→ dispatch governance-drift（run 32340796801）→ 检出：DRIFT repo 'agent-tools' required check 'gate' 活体缺失：最近 3 个已完结 CI 的 head 均无该 check run——job 改名或 workflow 重构？裸奔窗口已开启 → 报告进 auto-drift-report issue 治理漂移检测：组织配置与 governance/ 落盘不一致 #107（GM-1 通道）。
• 还原（关闭注入 PR + 删分支）→ 复跑 run 32341114190 → OK required-check-live 'agent-tools' ✅（issue 自动关闭依赖其余漂移清零，见下方已知项）。

T1 过程中修掉的两个真实检测缺陷（PR #111 + #120，均 ADR-0034 框架内修订）：

1. 起飞窗口误报（实测 mutual：三连新开 PR 的 CI 起飞窗口内 gate 未报 conclusion 被误判缺失）→ in-flight head 不构成证据；关闭未合并 PR 不采样；全部 in-flight 显式 SKIP。
2. 采样位移漏检（实测：并发连开 PR 把注入头挤出「前3」、in-flight 头白占采样位）→ 改为先跳过 in-flight 再收集最近 3 个已完结 head（最多扫 10 个候选）。

T2 PR liveness 注入（负向） ✅：dispatch liveness_hours=0（run 32337985794）→ 检出两类并进 issue #107 评论：Use-up-Plan PR#33 auto-merge 已开启但 0h 无进展——卡死侦测 (a)（注入：对 gate 改名 PR 开 auto-merge → 永久挂起）；AI_Web_School PR#49 check 'check / check' 停留 in_progress——卡死侦测 (b)（同阈值 0 下的正常瞬间态，证明 (b) 判据工作）。(c) 零-check 形态由改名 PR 的对照覆盖（head 有其他 check 但 gate 缺失 → §12 路径）。

T3 误报控制（正向 soak） ⏳：改为观察期项——实现首日已在真实流量上抓到并修复两类误报形态（起飞窗口/采样位移），修复版连续本地全量实跑（≥3 次）11 仓零误报；连续 3 天小时级 soak 由 CI 自然执行（出现误报按卡内要求修判定逻辑，不调阈值掩盖）。

遗留（非本卡范围，已登记）：① merge-queue ruleset 应用失败（#92 诊断评论：org API 不支持 merge_queue 规则类型）；② Shorts_Director 直推 f63baf26 待 24h 内回填（§8 既有通道）。P1-4 完成，关闭。