When a branch is pushed directly to this repo (not a fork) and a PR is then opened from it, the `Build` workflow was running twice for the exact same commit — once for the `push` event and once for the `pull_request` event — because it was declared as `on: [push, pull_request]` with no branch filter.

What changed

• Restricted the `push` trigger in build.yml to `main`, `develop`, `support-*` (maintenance branches like `support-7.0` that also get direct pushes/backports), and tags (needed for the NuGet publish/attest steps gated on `refs/tags/` — this repo's release tags are bare semver like `8.10.0`, not `v`-prefixed). Topic/feature branches (which don't follow a consistent naming convention in this repo) no longer trigger a `push`-based run — only `pull_request` covers them.
• Added a `concurrency` group (keyed by PR number, falling back to ref for plain pushes) with `cancel-in-progress: true`, so a stale run for the same branch/PR is cancelled when a newer one starts. Note: this doesn't dedupe the push-vs-pull_request case itself — that's handled by the branch restriction above — it just avoids piling up redundant runs within the same trigger type (e.g. rapid-fire pushes to `develop`, or repeated `synchronize` events on a PR).

Not touched

• codeql.yml already scopes `push` to `develop`/`main`/`release*`, so it doesn't have this problem.
• code_quality.yml / code_quality_pr.yml are already split into push-only and PR-only workflows.

Reviewer notes

No public API, test, or documentation changes — this is CI configuration only.

🤖 Generated with Claude Code