ci: #3039 让 main 每个 SHA 的 harness-verify 各自成组后，合并密集时 run 堆积、把 backend-gates 部署链饿死——需要「被取代的 SHA 可取消、部署链优先」

## 现象（2026-09-08 09:30Z–10:40Z）
#3039 之后 main 每个 push 的 `harness-verify` 各自成组、不再互相顶掉（修的是 #3038「main 永远没验证」）。但合并密集时（本日 09:24–10:34 共 6 次 push main），每次 push 同时触发 `harness-verify`（多 job）与 `backend-gates`（含 deploy），托管 runner 池被 harness-verify 占满：
- harness-verify：6 in_progress + 9 queued（其中 main push 3 in_progress + 5 queued）
- backend-gates main：5 条 queued **2.5 小时**，含 P0 修复 #3065 的部署链一直没 runner。

coordinator 手动取消了 7 条被更新 SHA 取代的 main harness-verify（保留最新 SHA 的那条）才让部署链有机会。

## 根因
两个目标冲突：「每个 SHA 都验证」（#3038 的修法）vs「部署链优先」。托管并发是组织级上限，两条 workflow 共用。

## 建议
1. `harness-verify` 的 push-main 组改回按 ref 且 `cancel-in-progress: true`——被更新 SHA 取代的中间 SHA 验证取消是可接受的（最新 SHA 仍验证）；**dispatch 仍各自成组**（保住 #3038 修的手动派发不被顶）。
2. `backend-gates` 保持每 SHA 一组（deploy 串行由 `workspacex-devapp-deploy` 组保证），但给 gates-* job 更高优先级——GitHub 无优先级机制，替代：合并密集期由 coordinator 限制 dispatch，或把 e2e-full 从 harness-verify 的 push 触发里拿掉（只 dispatch/schedule）。
3. 记入 coordinator SOP：`queued > 5` 不派新 lane；PR 合入后立刻取消其 lane。

Start by locating the workflow definitions for harness-verify and backend-gates and review their concurrency behavior for push and dispatch events. Reproduce the dense-merge scenario or inspect queued runs, then verify that superseded main SHA runs are cancelled while dispatch runs remain independent and backend-gates can proceed. Record the queued-run and lane-cancellation rules in the coordinator SOP.

Written by the indexing model from the issue text.