[Bug]: main 连续合并时 CI 互相取消，红叉盖住真实结论 #608

问题

.github/workflows/backend.yml 和 .github/workflows/frontend-ci.yml 都开着 cancel-in-progress: true，并发组分别是 ci-${{ github.ref }} 和 frontend-ci-${{ github.event.pull_request.number || github.ref }}。

分支和 PR 上这是对的：同一分支新 push 取消旧 run，省额度。但 main 上所有 push 共用同一个 ref，于是后一次合并会把前一次还在跑的 run 掐掉。

8/24 05:30:45 到 05:32:31，两分钟内连着合了 #553、#578、#576、#586、#587 五个 PR，前四个的 Frontend CI 与 Backend CI 全部被后面的合并取消。提交列表里这五行都显示红叉——GitHub 把 cancelled 汇总进 failure 状态，看不出是取消还是真挂。

为什么现在提

红叉本身只是观感，真正的代价是它把真实结论盖掉了。

把这五个合并提交的 run 重跑了一遍，其中 #587（6908e2b）的 Frontend checks 跑出的是 failure 而不是 success：

FAIL src/pages/playtest/index.test.tsx > PlaytestPage >
     uses the project movement mode to play an eight-way diagonal sequence
AssertionError: expected 'https://cdn.windup.test/walk-north.png'
              to be 'https://cdn.windup.test/walk-north_east.png'
Test Files  1 failed | 71 passed (72)

同一个 sha 不改任何代码再跑一次（attempt 3）就过了，所以这条用例是不稳定的，6908e2b 那次合并并没有真的把 main 弄红。

但这恰恰是问题所在：从提交列表上看，取消、真失败、不稳定用例偶发失败，三者是同一个红叉。要分辨只能一个个手动重跑——本次就是这么查出来的，十个 run 逐个补跑之后才确认全部为绿。取消策略把「这个 commit 的 CI 到底什么结论」这个信息整个抹掉了。

（不稳定用例本身的修复另行跟进，不在本 issue 范围内。）

范围

• main 上的 push 按 commit 分组，每个合并提交各自跑完，不再被后一次合并取消
• 其他分支和 PR 保持现状：新 run 仍然取消旧 run，额度照省
• 两个 workflow 一起改，口径一致

不包含

• 不动 CI 的检查内容、触发条件、权限声明
• 不引入 merge queue，也不改 main 的分支保护规则
• 不处理上面那条 playtest 八向用例的定性

验收

• 连着合两个以上 PR 到 main，每个合并提交都有属于自己的 CI 结论，提交列表里不再出现 cancelled
• 同一个 PR 上连续 push 时，旧 run 仍然被新 run 取消