Pin the AWS provider to ~> 6.64.0 and commit the lock file

[ale210]

Closes #181.

This repository declared no required_providers block anywhere in terraform/*.tf, so nothing constrained hashicorp/aws, and .gitignore ignored the lock file. Every CI run installed whatever the newest AWS provider happened to be that day. Since this repository manages IAM -- users, groups, policies and the OIDC providers other repositories authenticate through -- an unreviewed provider upgrade lands on the account's access control.

Changes

• terraform/backend.tf -- added a required_providers block inside the existing terraform { }, pinning hashicorp/aws at ~> 6.64.0. Three parts, not two: ~> 6.64 would allow every 6.x and would not fix this.
• .gitignore -- removed *.terraform.lock.hcl and its now-orphaned # Ignore lock file header. The .terraform/ directory entries are untouched. The file also gains the trailing newline it was missing.
• terraform/.terraform.lock.hcl -- generated with terraform providers lock -platform=linux_amd64 -platform=windows_amd64 and committed. Both platforms are needed because CI runs on ubuntu-latest while local work is on Windows.

Why 6.64.0 rather than the 6.62.0 named in the issue

The issue was written on 2026-08-30, when 6.62.0 was the latest release; 6.64.0 is the current latest. The most recent apply run here installed 6.63.0, and the most recent apply on hackforla/incubator installed 6.64.0. The issue asks for both repositories to be pinned to the same version so they cannot diverge against account 035866691871, and 6.64.0 is the higher of the two, so neither state ends up written by a provider newer than its own pin. hackforla/incubator#192 pins to the same version in the same pass.

Verification

terraform validate passes and terraform fmt -check is clean on backend.tf. Both providers in the lock file carry two h1: hashes, one per platform, and the aws entry records constraints = "~> 6.64.0", which confirms the new block is read rather than the version merely resolved.

The plan run on this PR is the real check -- it should still report "No changes. Your infrastructure matches the configuration." Any change appearing now is caused by the pin and needs to be understood before merging rather than applied.

The issue's last action item is post-merge and stays open until then: confirm the next plan run installs the pinned version rather than resolving a fresh one. That is also what settles the genuinely untested question of whether dflook/terraform-plan@v1 honours a committed lock file, since until now there was no committed lock file for it to honour.

Note on tls

The lock file also pins hashicorp/tls, which nothing constrains, and resolves it to 4.4.0. This is not a change to what CI was doing -- with no lock file it was already installing the latest tls on every run. Only aws gets a required_providers constraint.

[github-actions]

Terraform plan in terraform
With backend config files: terraform/prod.backend.tfvars

No changes. Your infrastructure matches the configuration.

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration
and found no differences, so no changes are needed.

✅ Plan applied in Apply Terraform changes on merge #45