build(terraform): record linux_amd64/linux_arm64 provider hashes in every lock file and init the env roots with -lockfile=readonly #1435

What happens

Most committed .terraform.lock.hcl files record provider h1: hashes for one platform only (from the PR history, darwin). On Linux, strict init fails:

$ terraform version            # Terraform v1.10.5, linux_amd64
$ cd terraform/modules/build    # clean copy of main at 6b586cc2
$ terraform init -backend=false -lockfile=readonly -input=false
...Terraform has been successfully initialized!
$ terraform validate
Error: registry.terraform.io/hashicorp/external: the cached package for registry.terraform.io/hashicorp/external 2.3.5 (in .terraform/providers) does not match any of the checksums recorded in the dependency lock file

A plain terraform init works, but it quietly adds the Linux hashes to the working copy, so every Linux init leaves the lock file modified.

Scope on main (6b586cc)

24 of the 42 committed lock files have only one h1: hash per provider:

• iac/federation/aws-cross-account/terraform
• iac/federation/aws-target/terraform
• iac/federation/gcp-sa-impersonation/terraform
• iac/federation/gcp-target/terraform
• terraform/environments/aws/ci-cd-permissions
• terraform/environments/azure
• terraform/environments/azure/ci-cd-permissions
• terraform/environments/gcp
• terraform/environments/gcp/ci-cd-permissions
• terraform/modules/build
• terraform/modules/compute/azure/container-apps
• terraform/modules/compute/gcp/cloud-run
• terraform/modules/compute/gcp/gke
• terraform/modules/database/aws
• terraform/modules/email/azure
• terraform/modules/frontend/{aws,azure,gcp}
• terraform/modules/iam/azure/cudly-reservation-role
• terraform/modules/networking/{azure,gcp}
• terraform/modules/secrets/{aws,azure,gcp}

(terraform/environments/aws already has three platforms' hashes since #1106.)

CI copes only because the Terraform Init step in .github/workflows/ci.yml runs plain terraform init -backend=false on the environment roots. The module-test steps that use -lockfile=readonly only touch modules whose locks already have Linux hashes, which is why #1086 had to add them to modules/database/aws. The deploy jobs also use plain init, on both ARM (ubuntu-24.04-arm) and x86 runners.

Impact

This is not a security hole: downloads are still checked against the registry-signed zh: hashes. The cost is broken strict checks on Linux for developers and agents, lock files that change on every Linux init, and new modules that cannot get readonly tests in CI without a lock fix first.

Suggested fix

One PR, provider versions unchanged:

• regenerate each listed lock file with terraform providers lock -platform=linux_amd64 -platform=linux_arm64 -platform=darwin_arm64 -platform=darwin_amd64 (linux_arm64 because the deploy jobs and the heavy CI jobs run on ARM runners);
• add -lockfile=readonly to the Terraform Init step in ci.yml, so a single-platform lock cannot come back.

Open PRs that also edit lock files (#1086, #1090, #1309, #1312) should land first, or be reconciled.

Acceptance criteria

• Every committed lock file has h1: hashes for linux_amd64, linux_arm64, darwin_arm64 and darwin_amd64, with the same provider versions as before.
• terraform init -backend=false -lockfile=readonly followed by terraform validate passes on linux/amd64 for every environment root and every module with tests.
• CI's environment-root init uses -lockfile=readonly.

Filed by IAmJSD's agent at IAmJSD's request (acting owner while the maintainers are away).