Runs on main are cancelled by the next merge, so a commit's checks never complete

> 🤖 Generated by the Agentic Engineer

## Evidence

`concurrency.cancel-in-progress: true` in `.github/workflows/ci.yaml` is keyed on
`ci-ksail-${{ github.workflow }}-${{ github.ref }}`. On `main` every merge shares one `github.ref`, so
a merge landing while the previous merge's checks are still running **evicts them**.

That is how the breakage in #6373 reached `main` unseen. `59cb206dc8` (the `#6363` merge) changed
`internal/ciharness/system_test_harness_test.go`, which matches the Go path filter — the tests were
not skipped, they were **cancelled** mid-flight by the next merge. `#6373`'s own evidence table records
`59cb206dc8` as `cancelled` for both `🧪 Test` and `🛡️ Vulnerability Scan`.

A cancelled check is not a failed check, so branch protection and the commit status both settle on a
green-looking `main` while the verification that would have caught the regression never completed.

## Affected audience and impact

Everyone who trusts `main`'s status, and every subsequent PR author. The eviction is silent and
timing-dependent, so it is most likely exactly when it hurts most — during a burst of merges — and the
inherited breakage then presents as the *next* unrelated PR's problem.

## Expected behaviour

On a pull request, cancelling superseded runs is correct and should stay: only the newest commit's
result matters.

On the default branch it is wrong. Each merge commit's run **is** the verification record for that
commit, and it is not superseded by a later commit — a later commit is a different subject. Runs on
`main` should be allowed to finish.

## Acceptance criteria

- [ ] Runs on the default branch are not cancelled by a subsequent push to the default branch.
- [ ] Cancellation behaviour on pull requests is unchanged (superseded PR runs still cancel).
- [ ] A deliberate probe demonstrates the change: two merges to `main` in quick succession both retain
completed `🧪 Test` results, where today the first is `cancelled`.
- [ ] Check whether any other workflow in this repo shares the same ref-keyed cancellation on `main`
(`cd.yaml`, the system-test workflows) and fix or reason about each.

The usual shape is `cancel-in-progress: ${{ github.ref != 'refs/heads/main' }}`, but confirm that
against how the merge queue interacts with it before adopting it — this repo gates `main` behind a
merge queue, and `merge_group` refs must not be starved either.

## Size

Small — a one-line expression plus the probe. The care is in the merge-queue interaction, not the edit.

Part of #6373