feat(tra-1062): pin OpenTofu version in CI and bound required_version

[mikestankavich]

Closes TRA-1062.

Problem

All four opentofu/setup-opentofu@v1 steps ran without tofu_version, so CI silently tracked whatever latest was on the day the job ran. A green run today and a red run next week could differ only by an upstream OpenTofu release, with nothing in the repo changed to explain it.

Change

• .opentofu-version at the repo root, read by setup-opentofu's native tofu_version_file input. Version lives in exactly one place; a bump is a one-line diff.
• Pinned to 1.12.5 — what CI was already resolving latest to, and what the workstation now runs. This codifies the current state rather than moving anything.
• required_version bounded from >= 1.0.0 to ~> 1.12 across all five roots, so an unintended major/minor jump fails loudly at init instead of silently applying.

Verification

Run locally on 1.12.5:

Check	Result
tofu fmt -check -recursive terraform/	clean, exit 0
init -backend=false + validate, all 5 roots	pass
Lock-file churn	none
State rewritten	none — remote serials unchanged

The guard was verified to actually bite, not just assumed. Against the new constraint, 1.11.6 exits 1:

Error: Unsupported OpenTofu Core version
  on provider.tf line 2, in terraform:
   2:   required_version = "~> 1.12"
This configuration does not support OpenTofu version 1.11.6.

Notes

Two things worth flagging for review:

• This closes the 1.11.x rollback path. ~> 1.12 means init refuses to run on 1.11.6. Chosen deliberately over leaving >= 1.0.0, on the grounds that catching an unintended jump is worth more than preserving a downgrade we have no current reason to make. Rollback within 1.12.x is unaffected.
• Lock-file churn is latent, not absent. 1.12's provider-checksum change makes init add h1: hashes, but only when re-resolving from scratch. With .terraform/ caches present it is a no-op, which is why this PR carries no lock diff. Expect the churn on the next fresh clone or new worktree; it is additive and backward-compatible.

The terraform-azure plan job runs on this PR (the workflow file is in the touched paths), which exercises the new pin end-to-end on a job that actually reaches a backend.

🤖 Generated with Claude Code

[github-actions]

Terraform Plan (terraform/azure)

Plan output unavailable (likely a job failure before plan completed). See the workflow logs for details.

Error: ENOENT: no such file or directory, open 'terraform/azure/plan_output.txt'

[github-actions]

Terraform Plan (terraform/azure)

Plan output unavailable (likely a job failure before plan completed). See the workflow logs for details.

Error: ENOENT: no such file or directory, open 'terraform/azure/plan_output.txt'

[github-actions]

Terraform Plan (terraform/azure)

Plan output unavailable (likely a job failure before plan completed). See the workflow logs for details.

Error: ENOENT: no such file or directory, open 'terraform/azure/plan_output.txt'

[mikestankavich]

Verified the pin is actually load-bearing

The initial green run didn't prove much on its own: the step logs tofu_version_file: .opentofu-version next to the default tofu_version: latest, the action never prints the resolved version, and latest happens to be 1.12.5 right now — so a silently-ignored file would look identical to a working one.

Proved it with a temporary commit setting .opentofu-version to 1.11.6 (since reverted, branch force-pushed back to 22ec03c). All five tofu validate jobs failed:

Error: Unsupported OpenTofu Core version
This configuration does not support OpenTofu version 1.11.6.

That confirms two things at once: tofu_version_file overrides the latest default, and the new ~> 1.12 guard fires in CI, not just on a workstation.

Current run on 22ec03c: tofu fmt and all five tofu validate jobs pass. All six required contexts are green.

The failing plan job is unrelated

terraform-azure / plan fails at azure/login@v2, before setup-opentofu ever runs:

AADSTS700016: Application with identifier '***' was not found in the directory '***'

The app registration is gone with the AKS burn-down (TRA-976); Azure and AWS are inactive. Not a required context, so the PR is MERGEABLE. Worth noting this workflow only triggers on terraform/azure/** or its own file, so it went unnoticed until this PR touched the workflow — it will stay red on any future Azure-touching PR until the stack is rebuilt or the workflow is gated on the environment being live.