chore(iac/federation): align provider version floors in customer onboarding bundles

[cristim]

Problem

INF-08 (#1188, PR #1242) aligned the ~> X provider floors across terraform/modules/** and terraform/environments/** to stop module-local lock files from drifting to provider majors no consuming root ever applies.

The same >= X.0 unbounded floor pattern is present in the per-customer federation bundles under iac/federation/**. Each one will resolve to whichever provider major Terraform sees as newest at the customer's terraform init time, which means two customers onboarding a few months apart end up locked to different provider majors with no version policy on our side.

Per iac/federation/*/terraform/main.tf today:

Bundle	Provider	Current constraint	Risk
aws-cross-account	hashicorp/aws	>= 5.0	resolves to whatever AWS major is current at customer init time
aws-target	hashicorp/aws	>= 5.0	same
gcp-target	hashicorp/google	>= 5.0	same for google
gcp-sa-impersonation	hashicorp/google	>= 5.0	same for google
azure-target	hashicorp/azurerm	~> 4.0	already pinned (intentionally on the 4.x line, distinct from the host-side terraform/environments/azure 3.x line)

The azure-target ~> 4.0 is fine and intentional — it's the cross-major split the cudly-reservation-role module's >= 3.0 constraint accommodates (#1242).

The AWS and GCP bundles are the ones that need a deliberate floor.

Why this matters

These bundles are run by customers on their own AWS/GCP accounts as part of CUDly onboarding. Each customer brings their own state and lock files. Today:

• A customer onboarding now resolves >= 5.0 AWS to whatever 6.x is current; a customer who onboarded 12 months ago landed on 5.x.
• Our docs, support tickets, and reproduction steps cover whichever provider the doc author had locally at the time of writing.
• If a future schema break ships in a provider major, customers on the new major silently get a different plan diff for the same .tf source than customers on the old major.
• Our regression-test stories (e.g. role-parity ARM/TF parity guard, federation smoke tests) cover one provider major at a time.

This is the same drift class INF-08 fixed inside terraform/; we just didn't extend it across the boundary into the customer-facing bundles.

Proposal

Pin each AWS and GCP federation bundle to the same major line our internal modules use, so docs and reproduction stay consistent:

• iac/federation/aws-cross-account/terraform/main.tf: aws = "~> 5.0"
• iac/federation/aws-target/terraform/main.tf: aws = "~> 5.0"
• iac/federation/gcp-target/terraform/main.tf: google = "~> 5.0"
• iac/federation/gcp-sa-impersonation/terraform/main.tf: google = "~> 5.0"
• Leave azure-target at ~> 4.0 (deliberate cross-major split with the host-side ~> 3.0).

Optionally also align the http, random, and azuread sub-providers in those same files (currently a mix of >= 3.4, >= 3.0, ~> 3.8, ~> 2.0) so customers see consistent supply-chain pins.

No committed lock files exist under iac/federation/** today (customers generate their own), so there is no lock churn to manage on our side. Pure source-file change plus a docs note in the README of each bundle.

Acceptance

• AWS and GCP federation bundles use ~> 5.0 floors matching the internal modules; azurerm left at ~> 4.0.
• terraform init -backend=false && terraform validate clean in each of the five bundle directories.
• README for each bundle mentions the pinned major and how a customer should bump when CUDly migrates the host-side line.

Out of scope

• Migrating the host-side azurerm line from ~> 3.0 to ~> 4.0 — that's a much bigger lift (schema migration across every azurerm consumer in terraform/).
• Adding any new permissions to the bundles. Pure version-pin alignment.

Discovered during the adversarial review of #1242.