Cancel superseded CI runs with a concurrency group

[arpastrana]

Adds a concurrency group to build.yml, docs.yml and pr-checks.yml, and workflow_dispatch to the first two. Mirrors how jax_fdm arranges the same workflows.

Why

Triggers were already scoped correctly — both workflows fire on push to main and pull_request against main, and no run in recent history came from a push to a feature branch. What was missing is cancellation of superseded runs.

phase-2 shows the cost: pushing to the branch while checks were running produced three build runs, three docs runs and two verify-pr-checklist runs, of which only the last of each mattered. With this, that becomes one of each.

How

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}-${{ github.event_name == 'pull_request' && 'pr' || github.run_id }}
  cancel-in-progress: ${{ github.event_name == 'pull_request' }}

Pull request events share a group per branch, so a new push cancels the run it supersedes. Every other event gets a run-unique group via github.run_id and never cancels, so a stuck run cannot hold up a push to main or a release tag.

pr-checks.yml is pull_request-only, so it takes the simpler unconditional form.

Deliberately unchanged

The dev-docs job keeps its own job-level concurrency: {group: dev-docs, cancel-in-progress: false}. That one serialises gh-pages writes so two merges cannot race on the same branch, which is a different concern from cancelling superseded runs — the workflow-level group never cancels a push event anyway.

No change to which events trigger CI.