Set concurrency limit of 1 for deploy-development and deploy-production jobs

[Copilot]

Concurrent deploy jobs (e.g. from rapid pushes or manual triggers) could race against each other, causing unpredictable deployment state for both dev and prod environments.

Changes

• Added concurrency blocks to deploy-development and deploy-production jobs in Build-Test-And-Deploy.yml
  • Fixed group names (deploy-development, deploy-production) scope the lock globally across all workflow runs
  • cancel-in-progress: false queues new runs rather than cancelling the in-flight deployment

concurrency:
  group: deploy-development   # or deploy-production
  cancel-in-progress: false

Original prompt

Set the GitHub actions concurrency (https://docs.github.com/en/actions/how-tos/write-workflows/choose-when-workflows-run/control-workflow-concurrency) for deploy development jobs that can run at the same time even between workflows as 1 and the same for deploy prod.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[Copilot]

Pull request overview

This PR adds concurrency controls to the deployment jobs in the GitHub Actions workflow to prevent race conditions when multiple deployments are triggered simultaneously (e.g., from rapid pushes to main or manual workflow triggers).

Changes:

• Added concurrency blocks to both deploy-development and deploy-production jobs with fixed group names and cancel-in-progress: false to queue deployments rather than cancel them