ci(regression): add concurrency group to cancel superseded runs

[jrusso1020]

What

Adds a concurrency: block to .github/workflows/regression.yml that cancels any in-progress regression run when a new commit is pushed to the same ref.

Why

Matches the pattern already in place on every other workflow in the repo:

Workflow	Concurrency
ci.yml	✅
docs.yml	✅
catalog-previews.yml	✅
windows-render.yml	✅
publish.yml	N/A (deliberately never cancelled — avoid half-published tags)
regression.yml	❌ ← this PR

regression.yml is also the biggest matrix workflow (styles-a through styles-g, fast, render-compat, hdr — ~10 parallel shards plus setup/detect jobs per run). Without a concurrency group, rapid pushes to a PR leave prior regression runs consuming the full matrix even though their outputs will be thrown away.

Triggered by the queue state from earlier this afternoon — 34 queued vs 7 in-progress jobs across the repo, much of it regression shards on superseded commits. Fixing this alone should noticeably reduce queue depth under normal push cadence.

How

Using the exact same pattern as ci.yml and the others — group: regression-${{ github.ref }} with cancel-in-progress: true. For pull_request events, github.ref is refs/pull/<number>/merge (unique per PR), so only pushes to the same PR cancel the prior run. For pushes to main, all workflows in the repo use the same cancel-in-progress semantics, so regression stays consistent.

Test plan

• Unit tests added/updated — N/A (workflow config)
• Manual testing performed — verified YAML is syntactically valid and follows the exact shape used by the 4 other workflows in the repo that already have concurrency blocks
• Documentation updated (if applicable) — N/A

Once this merges, push a second commit to any PR with a touched packages/producer/** file and confirm the first regression run gets cancelled.