fix(ci): pull_request 事件偶发不触发 harness-verify —— 已连撞两次（#1171、#1227）

## 症状

某些 PR 的 `harness-verify` workflow 完全不触发（`gh pr checks` 报 `no checks reported`，`gh run list --branch <分支>` 零命中），不是 workflow 本身的分支过滤问题——同一时刻其他 `worker/**` 分支的 PR 都能正常触发 `pull_request` 事件。

## 已知实例

1. **PR #1171**（F176 signoff 追加）：同一症状，当时用重推/force-push 后自然恢复。
2. **PR #1227**（F176 实现，`worker/org-admin-quota-01-F176`）：CI 完全没触发。coord-main 用 `gh workflow run harness-verify.yml --ref worker/org-admin-quota-01-F176` 手动 dispatch 绕过（run `31780860211`），确认 `fullstack-smoke` pass，只有 `e2e-full` 命中已知的 chat-read flake（见 #485 最新评论）——代码本身没问题，是触发机制的问题。手动 dispatch 的结果**不会**附加到 PR 的 checks 列表上，无法作为正常合并门禁的证据。

## 影响

被这个问题命中的 PR 无法走正常的"CI 绿了就合"流程，只能靠 coordinator 手动 dispatch + 人工核对 job 级结果来代替，绕开了 PR 级别的 required checks gate——这本身也是一个信任链缺口（手动 dispatch 的结果理论上可以被伪造/误判，不像 PR checks 那样有 GitHub 自己的状态机背书）。

## 待排查

两次都发生在同一天内合并量很大的时段，可能与 GitHub Actions 的 webhook 投递延迟/丢失有关，也可能与仓库当时的并发 workflow 数量触顶有关。需要有人专门查一次 GitHub Actions 的 delivery log（Settings → Webhooks，如果有权限）或复现条件。

owner: coord-architecture（CI/workflow 基础设施域）

Start with harness-verify.yml and compare the missing pull_request runs for #1171 and #1227 using gh pr checks and gh run list --branch. If access is available, inspect the GitHub Actions delivery log for the affected period and compare it with normally triggered worker/** branches. Done means the trigger failure or reproducible condition is identified and normal PR checks reliably appear, without relying on manual workflow dispatch.

Written by the indexing model from the issue text.