Redesign docker-build.yml concurrency group to eliminate residual push/pull_request race

[Wikid82]

Background

.github/workflows/docker-build.yml's concurrency: group key is:

```yaml
concurrency:
group: ${{ github.workflow }}-${{ github.head_ref || github.event.workflow_run.head_branch || github.ref_name }}
cancel-in-progress: true
```

For a push event, github.head_ref is empty, so the group falls back to github.ref_name (e.g. main). For a pull_request event whose head branch is main, github.head_ref is literally main. Both resolve to the identical group string (e.g. Docker Build, Publish & Test-main) whenever a PR's head branch is main or development (the case for bot-generated "propagate main→development" / weekly promotion sync PRs).

What the companion fix (this PR) does and does not solve

A companion PR adds a job-level if: skip condition to the setup job so the pull_request-triggered instance for a main/development-head PR short-circuits to a clean skipped conclusion instead of relying on concurrency cancellation. This makes the losing run report skipped (which GitHub branch protection generally treats as satisfying a required check) instead of a misleading cancelled red X, in the commonly observed case where the pull_request run's setup job evaluates before the push run registers.

It does not eliminate the underlying registration-order race: GitHub's cancel-in-progress: true cancellation decision is made at workflow-run registration time, before any job's if: is evaluated. If a push event's run is genuinely mid-build and a pull_request run for the same commit registers afterward in the same concurrency group, the in-progress push run can still be cancelled by the concurrency subsystem — this fix does not influence that outcome in either direction, since it only changes what the pull_request run's own jobs report once they get a chance to evaluate, not which run "wins" the concurrency slot.

Proposed fix

Append the event name to the concurrency group key, e.g.:

```yaml
concurrency:
group: ${{ github.workflow }}-${{ github.head_ref || github.event.workflow_run.head_branch || github.ref_name }}-${{ github.event_name }}
cancel-in-progress: true
```

so that push and pull_request runs for the same branch never share a concurrency group at all, eliminating the race entirely (rather than just cleaning up its reported status in the common case).

Why this is out of scope for the companion fix

This is a materially larger, separately-scoped change — it needs its own review of every other place this workflow (and any workflow depending on its workflow_run completion, i.e. downstream consumers keyed on workflow_run.head_branch) assumes a shared concurrency group per branch, to confirm nothing relies on push and pull_request runs for the same branch currently deduplicating against each other via the shared group. That review is deliberately deferred to keep the companion fix a tight, low-risk, single-line functional change.

References

• Plan: docs/plans/current_spec.md ("Plan: Skip redundant pull_request docker-build run for main/development-head PRs"), §3.4.
• Precedent for tracking known-deferred fixes as issues rather than untracked prose notes: Orthrus dual-muzzle allowlist drift, GH orthrus: path-normalization order differs between backend and agent muzzle filters #1160/orthrus: unify the two independently hand-maintained muzzle allowlists (and give agent/ CI coverage) #1161.
• Companion PR: fix: skip redundant pull_request docker-build run for main/development-head PRs #1236