fix(ci): prevent duplicate production deployments with concurrency control

[pasevin]

Problem

Multiple production deployments were running simultaneously when multiple packages were released at the same time. Each package release triggers the production workflow, causing resource waste and potential deployment conflicts.

Current behavior:

• 4 packages released → 4 simultaneous production workflows
• All deployments run in parallel, wasting resources
• Potential for race conditions and conflicts

Root Cause

The production workflow triggers on:

on:
  release:
    types: [published]

When Changesets publishes multiple packages simultaneously, each creates a separate GitHub release, triggering multiple workflow runs.

Solution

Added concurrency control to the production workflow:

concurrency:
  group: production-deployment
  cancel-in-progress: true

Benefits

✅ Only one deployment at a time: Prevents resource waste
✅ Cancel redundant runs: New deployments cancel in-progress ones
✅ Simple & reliable: No need for complex filtering logic
✅ Future-proof: Works regardless of package count or release patterns

Testing

This fix will be tested automatically on the next package release. Expected behavior:

1. Multiple releases trigger multiple workflows
2. Only the latest workflow runs to completion
3. Earlier workflows are cancelled automatically

Alternative Solutions Considered

❌ Filter to specific package: Risk of missing deployments if package structure changes
❌ Time-based debouncing: Complex and error-prone
❌ Manual triggering: Requires human intervention

The concurrency approach is the most robust and maintenance-free solution.

[collins-w]

lgtm