fix(ci): stop no-op label events from cancelling PR deployments

The PR Deploy workflow shared one concurrency group across both its
`pull_request` and `pull_request_target` triggers with
`cancel-in-progress: true`. Any bot label landing while a deployment was
running entered the same group and cancelled it, then skipped every job
because check-options requires the label to be 'Needs: Deployment'. The PR
was left with cancelled/skipped deploy jobs and no explanation.

Label events that are not 'Needs: Deployment' now get a unique, throwaway
group so they cancel nothing. Real deployments — every `pull_request` run
and the 'Needs: Deployment' label run — stay in the shared per-PR group, so
a new push still cancels an in-flight deployment.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Author: flanakin

.github/workflows/ftk-pr-deploy.yml

@@ -29,8 +29,13 @@ env:
   AZ_RESOURCES_VERSION: '6.16.2'
   AZ_STORAGE_VERSION: '6.2.0'
 
+# Deploy runs for the same PR share one group so a new push cancels the
+# in-flight deployment. Label events that are NOT 'Needs: Deployment' are no-ops
+# (see the check-options condition below), so they get a unique, throwaway group
+# — otherwise an unrelated bot label would cancel a running deployment and leave
+# only skipped jobs behind, which reads as "deployment not requested".
 concurrency:
-  group: ftk-pr-${{ github.event.pull_request.number }}
+  group: "ftk-pr-${{ github.event.pull_request.number }}${{ (github.event_name == 'pull_request_target' && github.event.label.name != 'Needs: Deployment') && format('-noop-{0}', github.run_id) || '' }}"
   cancel-in-progress: true
 
 permissions: