fix(ci): a commit must not cancel another commit's run

[catomean]

The concurrency group was keyed by branch with cancel-in-progress: true, so a newer merge cancels an older commit's CI run — and every deploy path keys off that run:

• a deploy that waits for CI to pass on the commit finds a cancelled run and stops;
• a deploy chained on workflow_run sees conclusion: cancelled and skips.

auto-merge also re-arms CI with a dispatch, and under one group-per-branch that dispatch cancels the push run for the same commit.

It is not theoretical

Measured across the fleet on 2026-09-11: 28 of 39 ci.yml files had this shape. It broke two repos that day, in the two ways it can break.

repo	how it failed
fleetcrown	silently — Deploy skipped. Four merges sat on main, every check green, nothing red anywhere, box serving the previous build. Each needed a hand-dispatched deploy.
hirnli	loudly — Deploy errored at its wait-for-CI step. The better outcome, because somebody sees it.

20:24:07  push              cancelled   84403805
20:24:08  workflow_dispatch success     84403805   ← cancelled the one above

The change

Main is keyed per commit, so both runs finish and whatever the deploy path looks for is there. Branch behaviour is unchanged — the newest push is still the only one that matters there.

Upstream: bitbaum/fleet#53 fixes the templates this was copied from and adds a ci-strands-commits rule to the hygiene audit, so the remaining repos are found by a sweep rather than by an outage.

Workflow-only change: YAML parses and the jobs are intact. This PR's own CI run exercises the branch arm of the new expression.

🤖 Generated with Claude Code

https://claude.ai/code/session_018Z7YRpgsEtNjRqr1usHMQY