fix(ci): key rollback-aws-fargate on the Fargate Terraform state (#1857)

Fargate rollback wrote the Lambda Terraform state

rollback.yml's rollback-aws-fargate job built its backend key from the
Lambda state namespace, writing github-<env>/terraform.tfstate where every
other Fargate writer uses github-fargate-<env>/. A Fargate rollback
therefore initialised against the state the Lambda deploy owns and applied
compute_platform=fargate into it: against a populated Lambda state that is
a platform swap of the live Lambda stack recorded in the wrong file, while
the real Fargate state is left describing resources nobody reconciles. The
Lambda rollback job uses the same key correctly, so both rollback jobs were
writing one state file.

The key now matches the platform the job applies. Enumerated rather than
sampled: all 17 workflow files were swept for backend keys, compute_platform
vars and concurrency groups, and every writer cross-read in both directions.
Exactly one defective site, not two. The adjacent sites that are not
instances are recorded in the PR: the Azure blob has no platform split, GCP
uses prefix rather than key, and init-backend.sh emits an unprefixed key.

Blast radius, checked separately because a fix does not answer it:
rollback.yml has never run. The empty run list was validated in the other
direction by running the same query against ci.yml and getting rows back,
so it means no runs rather than a wrong filter. The corruption is latent,
nothing needs terraform state mv, and repointing the key strands nothing.
Not closed: reading the state object in S3 needs credentials unavailable
here, and a hand-run apply from a laptop would leave no trace in the repo.

A guard makes the pairing durable, since reading carefully once does not
survive the next edit. It sweeps the workflow directory and every script,
asserts the swept set is non-empty and contains the known site, and fails
if a job's backend key disagrees with the platform it applies.

Review found two ways that guard failed open, both fixed.

A job with the correct platform and key but no concurrency group at all
passed, because the group was only checked when non-empty. Absence was
read as an exemption rather than as a missing requirement, and such a job
can apply shared state with no workflow-level serialization. It is now two
independent conditions rather than an if/else on a non-empty group.

build_swept_scripts globbed only scripts/*.sh and scripts/lib/*.sh, so a
file at scripts/aws/rollback.sh was never opened while all three suites
reported coverage of every script under scripts/. Fixed in the shared
helper rather than locally, because the RDS and ECR guards call the same
function: mutation confirmed both of those suites, as merged on main, pass
with a nested offender present, so they have carried this blind spot since
#1852. Discovery uses find -print0 with read -d '' rather than a ** glob,
since globstar is bash 4 and these scripts run on the bash 3.2 that ships
with macOS, with sort -z for deterministic order and process substitution
so the array survives the loop.

Verified: mutations run against copies of the tree, each required to
produce its specific FAIL line since a syntax error also exits non-zero.
With a nested offender present all three suites now fail naming it, and
with it removed all three go green. ECR 48/48 and RDS 53/53 still pass
against the recursive helper.

Stated rather than glossed: scripts/ contains no nested *.sh today, so
recursive and non-recursive discovery return a byte-identical 26 files.
The recursion fix is preventive, and the recursion assertion runs against
a fixture tree, because asserting recursion where no nested file exists
would pass without testing anything.

Not verified: no terraform apply, init against a real backend, or destroy
was run, and neither destroy workflow was dispatched.

Deferred: #1856, database-migration.yml runs a bare terraform init with no
-backend-config in three jobs and swallows the real terraform error before
reading terraform output.

Author: cristim

.github/workflows/ci.yml

@@ -824,6 +824,40 @@ jobs:
       - name: Run RDS scope self-tests
         run: bash scripts/test-rds-deletion-protection-scope.sh
 
+  # Assert that every job applying a `compute_platform` writes the Terraform
+  # state namespace that platform owns: `compute_platform=lambda` into
+  # github-<env>/, `compute_platform=fargate` into github-fargate-<env>/. The
+  # AWS environment is one Terraform root applied twice into two state objects,
+  # nothing in Terraform ties the backend key to the platform, and a job that
+  # pairs them wrongly initialises, plans and applies cleanly while rewriting
+  # the other platform's stack and recording it in the wrong state file. That
+  # was #1811, where rollback.yml's Fargate rollback keyed on the Lambda
+  # namespace, so both rollback jobs wrote the same object. A workflow run
+  # proves nothing about this, so the pairing is asserted as text.
+  # Both directions are asserted, and the positive one first: the seven real
+  # pairings are named and checked before any absence, since a scan that
+  # recognizes no state-writing job has no violations either. The negative half
+  # is checked over a GLOB of .github/workflows and scripts/, not a list of
+  # known files, so a job added later is covered without anyone naming it.
+  # Fast (shell only), so it always runs.
+  aws-tfstate-platform-key:
+    name: AWS Terraform state namespace per platform
+    runs-on: ubuntu-latest
+    # Same shape as ecr-delete-selection above: this job checks out the tree and
+    # runs a shell script against it, so the repository-default read/write token
+    # is narrowed to `contents: read`.
+    permissions:
+      contents: read
+
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@93cb6efe18208431cddfb8368fd83d5badbf9bfd # v5.0.1
+        with:
+          persist-credentials: false
+
+      - name: Run state namespace self-tests
+        run: bash scripts/test-aws-tfstate-platform-key.sh
+
   # Assert that no Terraform file declares an azurerm_key_vault_access_policy
   # resource. This project's only Key Vault sets enable_rbac_authorization =
   # true, and an RBAC-enabled vault ignores access policies entirely, so such a
@@ -863,6 +897,7 @@ jobs:
       - gcp-secret-scope
       - ecr-delete-selection
       - rds-deletion-protection-scope
+      - aws-tfstate-platform-key
       - azure-kv-access-policy
     if: always()