fix(harness): spec 覆盖门控把 path-filtered 部署 job 算作覆盖 —— 共享包改动打红 devportal spec 时它不会触发

## 缺口

#512 / PR #515 新增的 `lint-spec-gate-coverage.mjs` 把 devportal 的 6 条 spec 判为 `covered`，**唯一来源是 `deploy-devportal.yml` 的 `pnpm --filter @repo/devportal run e2e`**。

⚠ 而那个 workflow 有 **`paths: apps/devportal/**` 触发过滤**。

⇒ **若某个共享包（`packages/contracts`、`packages/*` 等）的改动打红 devportal 的 spec，该 workflow 根本不会被触发。**

## 为什么这不是 #515 的缺陷

按门控当前的定义（「从 workflow 的 `run:` 可达即算覆盖」），#515 的判定是**正确的**。缺的是这个定义本身没区分两类 job：

| 类别 | 例子 | 性质 |
|---|---|---|
| **无条件门控 job** | `harness-verify`、`backend-gates` | 每次 push/PR 都跑 ⇒ 真覆盖 |
| **path-filtered 部署 job** | `deploy-devportal`（`paths: apps/devportal/**`） | 只在特定路径改动时跑 ⇒ **条件覆盖** |

由 PR #515 的复核提出，coord-main 采纳并单独立项。

## 为什么值得修

这与 #512 本身是**同一个形状**：`chat-read.spec.ts` 曾「写了但没人跑」；现在的风险是「**写了、名义上有人跑、但那个人只在某些改动下才来**」。

后者更隐蔽 —— 门控会报绿。

## 范围

1. 门控区分**无条件覆盖**与**条件覆盖**（path-filtered / 手动触发 / 定时）；
2. 条件覆盖的 spec 要么归入某个无条件 job，要么**显式署名豁免并写明理由**（照 `responsive.spec.ts` 的先例，#517）；
3. **反证**：把某条 spec 的唯一来源改成 path-filtered job → 门控必须把它从「无条件覆盖」降级并报出来。

⚠ **红了也要问是不是因为对的原因红的**（红线 10）：确认它红在「覆盖是有条件的」这个判据上，不是红在「job 名字变了」。

**Owner**：coord-architecture ｜ **优先级**：P2（不阻塞八步，但与 #512 同源）

Start with lint-spec-gate-coverage.mjs and the deploy-devportal workflow, then review the coverage behavior introduced by #515 and the exemption precedent in #517. Update the gate so path-filtered, manual, or scheduled jobs are not unconditional coverage; finish by adding the stated counterexample and verifying it fails for conditional coverage rather than a renamed job.

Written by the indexing model from the issue text.