chore(security): tighten Terraform provider constraints to exact pins

[jordanconway]

Summary

Replace all loose ~> and >= provider version constraints across all 7 OpenTofu modules with exact = X.Y.Z pins. This eliminates silent provider drift — with loose constraints, every tofu init could install a different version than the last run, and a compromised new release matching the range would be picked up automatically.

⚠️ This PR requires human review before merging. Changing version constraints can cause tofu init to fail if the environment uses cached provider binaries from a different version. Please validate in a non-production environment first.

ℹ️ Dependency note: This PR includes .terraform.lock.hcl via git add -f because the companion PR #8018 removes the *.lock.hcl gitignore entry. Either PR can merge first; if this merges before #8018, the lockfiles are tracked via force-add. If #8018 merges first, the force-add here is redundant but harmless.

---

Changes

Provider pins — all 7 modules

Module	Provider	Old constraint	New constraint	Resolved version
root	hashicorp/aws	~> 5.5	= 5.100.0	5.100.0
root	hashicorp/random	~> 3.4.2	= 3.4.3	3.4.3
modules/webhook	hashicorp/aws	~> 5.5	= 5.100.0	5.100.0
modules/download-lambda	hashicorp/null	~> 3.2.1	= 3.2.4	3.2.4
modules/runners-instances	hashicorp/aws	~> 5.5	= 5.100.0	5.100.0
modules/setup-iam-permissions	hashicorp/aws	~> 5.5	= 5.100.0	5.100.0
modules/runners	hashicorp/aws	~> 5.5	= 5.100.0	5.100.0
modules/runner-binaries-syncer	hashicorp/aws	~> 5.5	= 5.100.0	5.100.0

All versions were verified against the OpenTofu registry and confirmed as the latest that satisfied each prior constraint. All providers are signed with HashiCorp key 0C0AF313E5FD9F80.

Intentionally unchanged: required_version

The required_version = ">= 1.5" directive (which governs the OpenTofu CLI binary) is left as-is. Pinning it to a single exact version would break anyone running a different tofu release without a coordinated team upgrade. A separate decision is recommended to align CI (tflint.yml currently installs 1.5.7) with the version in active use locally.

Lockfiles updated

Both .terraform.lock.hcl files are regenerated to reflect the updated constraints = field, keeping them consistent with the new exact pins.

---

Keeping providers up to date going forward

When a Dependabot PR bumps a provider (or you want to upgrade manually):

# 1. Update the = X.Y.Z version in the relevant main.tf
# 2. Reinitialise
cd terraform-aws-github-runner
tofu init -upgrade

# 3. Regenerate multi-platform lockfile hashes
tofu providers lock \
  -platform=linux_amd64 -platform=linux_arm64 \
  -platform=darwin_arm64 -platform=darwin_amd64

# 4. Commit both main.tf and .terraform.lock.hcl

---

This change is part of a broader supply-chain hardening effort following a repository audit. See https://github.com/jordanconway/package-manager-hardening for the full methodology.

[vercel]

@jordanconway is attempting to deploy a commit to the Meta Open Source Team on Vercel.

A member of the Team first needs to authorize it.

[malfet]

Change LGTM, but I'm not sure why do you want to commit lock files, as they should not change across the runs, should they?

IMO one can have either strict constraints and no lockfiles (as they are redundant) or check in lockfiles but still have loose constraints, so that one can run an update command to change lockfile versions.

[jordanconway]

@malfet Ideally they wouldn't change but because they do contain hashes of the registry zip and the extracted binary and it can help prevent tag push style takeovers. I've got some more information documented here https://github.com/jordanconway/package-manager-hardening/blob/main/docs/terraform.md#lockfile
Hashicorp Terraform engineers have also suggested that lockfiles should be committed https://discuss.hashicorp.com/t/how-should-we-be-using-dependency-lock-files-in-ci/31728/3
That said, imo tight version pinning is more important here than lockfiles and if it introduces too much complexity I could be convinced to drop them.