chore: modernize Terraform and provider versions

[JoshLuedeman]

Summary

Modernize version constraints.

Changes

• Terraform >= 1.3 → >= 1.9
• azurerm ~> 3.36 → ~> 3.116
• Other providers (random, time, null) unchanged

Closes #1

[JoshLuedeman]

@copilot review this PR

[Copilot]

@copilot review this PR

Here's my review of the changes in this PR:

Changes made (infrastructure/terraform/versions.tf):

• required_version: >= 1.3 → >= 1.9
• azurerm provider: ~> 3.36 → ~> 3.116

---

✅ What looks good

• The version bump is surgical — only the two stale constraints are changed, nothing else is touched.
• ~> 3.116 is semantically equivalent to >= 3.116.0, < 4.0.0, which keeps the door open for future patch/minor updates without risking a v4 breaking change.
• Aligning the minimum Terraform version to 1.9 is reasonable; GA'd in mid-2024 and all major CI runtimes support it.

---

⚠️ Things to be aware of

1. azurerm 3.36 → 3.116 is ~80 minor versions. There are several deprecated arguments and renamed resources across that span. If this template's modules are wired to a Hub Landing Zone module (seen in 03-modules.workload.spoke.tf), that dependency should be verified to be compatible with azurerm ≥ 3.116 as well.

2. Submodule version files are inconsistent.
   modules/03-workload_spoke/versions.tf and modules/01-remote-state/versions.tf have no required_version or required_providers blocks — they will inherit whatever the caller supplies. This is a pre-existing gap, not introduced by this PR, but worth a follow-up to ensure consistent constraints across all entry points.

3. null provider has no version constraint in the root versions.tf (pre-existing). Low risk, but adds non-determinism to terraform init.

4. random is strictly pinned (= 3.4.3) while time is loose (0.8.0 with no pessimistic operator). Neither is changed by this PR, but they are worth normalizing in a follow-up.

---

Verdict: The PR is clean and correct for its stated purpose. The two version bumps are appropriate and the change scope is minimal. I'd suggest the submodule version-file inconsistency and the unpinned null provider be tracked as follow-up issues rather than blocking this PR.