ci: require AWS provider v6 in the Terraform tests

[bosconi]

Motivation

terraform-aws and terraform-aws-upgrade have failed on every nightly since #18164 (2026-08-25), six consecutive builds, plus both v26.40.0 RC nightlies. terraform init cannot resolve a provider:

Error: Failed to query available provider packages
Could not retrieve the list of available versions for provider
hashicorp/aws: no available releases match the given constraints
~> 5.0, >= 5.92.0, >= 6.0.0, ~> 6.0, >= 6.28.0, >= 6.59.0

test/terraform/ sources the self-managed modules at ref=main. Those modules moved to hashicorp/aws ~> 6.0 in MaterializeInc/materialize-terraform-self-managed#390 ("DEP-200 aws: upgrade to AWS provider v6 and EKS module v21"), merged 2026-08-25 19:08 UTC. Our providers.tf still pinned ~> 5.0, so the constraint set became unsatisfiable and the next nightly, which started 4h50m later, broke.

Description

Bump the hashicorp/aws constraint to ~> 6.0 in all three AWS configurations. aws-persistent is not in the failing set, but it sources the same modules at the same floating ref, so it carried the same unsatisfiable constraint and is fixed here too rather than left to surface later.

Only the AWS provider needed changing. The other constraints in those files (kubernetes, helm, random, kubectl) already resolved in the failing run.

Verification

Per directory, locally:

Directory	terraform init -backend=false	terraform validate
aws-temporary	resolves, aws 6.62.0	Success
aws-upgrade	resolves	Success
aws-persistent	resolves	Success

Tips for reviewer

This unblocks init; it may not be sufficient for apply. Upstream #390 also moved the EKS module to v21, and I have no AWS credentials to run a plan. The variable changes in that PR are purely additive with defaults, so our existing module calls stay valid — but one of the two new variables is worth flagging, because its own description names the failure mode:

partition — AWS partition (e.g. from a root-level aws_partition data source). Strongly recommended when this module call carries a depends_on: without it the upstream module looks the partition up via a count-gated data source, which a module-level depends_on defers to apply time, failing the plan with 'Invalid count argument' whenever the depended-on module has pending changes.

All three of our configurations call eks-node-group with depends_on = [module.eks] and none defines a root-level aws_partition or aws_caller_identity data source, so that trap applies to us. I have deliberately left it out of this PR to keep the diff to the one verified failure; if a nightly run hits Invalid count argument, the follow-up is to add those two data sources and pass partition/account_id to the eks-node-group calls.

Separately, sourcing these modules at ref=main is what let an upstream merge break our nightly with no PR-time signal. Pinning a tag or SHA would trade that for deliberate bumps; not proposed here.

🤖 Generated with Claude Code

[ggevay]

Oh, this seems to be the same thing as what I tried to do now in #38695
I ended up making a mess with it with doing a CI run, because it's not enough to bump the version, see the second commit of that PR. I've notified the cloud team, and I think we are unfortunately blocked on them, because the test can't be run now due to conflicts with the orphaned resources, and I don't dare trying to clean them up myself.

[bosconi]

I should have looped in the Cloud team once it was obvious that the version bump alone would cut it. Thank you for doing that. Once this is resolved, I will work with them to see if have to do anything special to get mz-context-graph upgraded.

[bobbyiliev]

Heads up, not closing since it's your PR, but #38695 has the same bump and its first commit is identical to this one, so only one should land.

[bosconi]

Superseded by #38695