lint-verification-can-fail 的 run 豁免是个洞：pnpm --filter X run <不存在的脚本> 同样恒 0（219 条命令受影响）

## 实测

```
pnpm --filter web no-such-script-zzz → 退出 0
pnpm --filter web run no-such-script-zzz → 退出 0 ← 洞在这
pnpm --filter web exec no-such-cmd-zzz → 退出 254
```

`lint-verification-can-fail.mjs` 的恒 0 规则正则是：

```js
re: /^pnpm\s+(?:--filter\s+\S+\s+)+(?!exec\b|run\b|dlx\b)\S/
```

它把 `run` 和 `exec` 一起排除，前提是「用了 run 就安全」。**这个前提不成立**——`pnpm --filter run <不存在的脚本>` 和裸词一样静默退出 0。

## 影响面

全仓 `phases/*/feature_list.json` 里有 **219 条** `pnpm --filter X run ...` 形态的 verification。

它们今天大多指向真实存在的脚本，所以能正常失败。风险是**静默衰减**：哪天脚本被改名或删掉，这条 verification 就从「会红」变成「恒 0」，而且**没有任何东西会提醒**——正是这个门存在的理由（V-1 事故：21 个 feature / 84 点靠一条恒 0 命令验收过）。

同一形状本会话已撞到过一次：`pr-queue.ts` 的 `REQUIRED_CHECKS` 写死了 job 名，job 一改名门就静默失效（#848 真实发生过，静默 5 天）。

## 为什么我不直接改

把 `run` 从排除列表拿掉，会**当场把 219 条命令判红**，拦住所有人。那正是 #848 的形状：一道门突然误拦，最后大家绕过工具。

这需要人决定节奏，我不单方面动。

## 三个选项

**A. 先加成 advisory，只记录不拦**（推荐）
参照 merge-gate 的 `MERGE_GATE_ADVISORY_ONLY` 做法：判定逻辑照跑、理由照打印、退出码不变红。先看清 219 条里有多少是真风险，再决定迁移。

**B. 逐批迁移到 `exec` 形态**
`pnpm --filter web run typecheck` → `pnpm --filter web exec tsc --noEmit`。已在 phase-10 的 F01/F03 上验证可行（本轮顺带做了，并给 `tsc --noEmit` 登记了形态与必然失败探针）。219 条要分批，每批一个 PR。

**C. 加一条实存核对，脚本存在就放行**
我一度实现了这个，**然后撤回了**——它只能证明「今天存在」，证明不了「不会静默衰减」，等于给这道门开后门。**不推荐**，记在这里是为了让下一个人不要重走。

## 相关

本轮同时发现 main 上三道控制面门同时红，性质各不相同：
- `lint-ui-material` —— 我自己 PR #1692 的残留 + `ui-material-map.json` 里 phase-10 键重复（JSON 静默取后者，前一份看得见但永不生效）
- `lint-verification-can-fail` —— 真问题，F01/F03 用了恒 0 形态
- `lint-third-artifact` —— 真实内容缺口，phase-10 五个束缺签核第 ③ 件

Start by reading lint-verification-can-fail.mjs and inspecting the 219 verification entries in phases/*/feature_list.json that use pnpm --filter X run. Compare the current rule with the three proposed approaches, then confirm the chosen rollout preserves existing checks while preventing or exposing silent success from missing scripts.

Written by the indexing model from the issue text.