ci: pin the self-managed Terraform modules to a tag instead of main

[bobbyiliev]

The test/terraform roots sourced every self-managed module at ref=main, so an upstream merge reached the nightly with no PR-time signal and no owner. DEP-200 moved the modules to AWS provider v6 and EKS module v21, the next nightly 4h50m later failed at terraform init on an unsatisfiable provider constraint, and both AWS steps stayed red for two weeks (DEP-245). Pinning turns that into a dependabot PR someone has to look at, and lets the roots be adapted in the same change as the bump that requires it. All 70 ?ref=main occurrences across the five roots move to v13.2.1, and a terraform ecosystem entry is added to dependabot so bumps keep arriving.

v13.2.1 is the tag at upstream main's current HEAD (09ab1c9), so this changes nothing about what the nightly runs today; it only changes how future upstream changes reach us. A tag rather than a commit SHA because dependabot does not reliably bump SHA refs (dependabot/dependabot-core#10787). The GCP and Azure roots are pinned too even though their nightlies are skipped, since leaving a floating ref behind just preserves the hazard for whenever they come back.

Test plan

terraform init -backend=false and terraform validate pass on aws-temporary with the pinned refs, with every module resolving at v13.2.1, and terraform fmt -check -recursive is clean. Because the pin equals current main, the AWS nightlies are the same check they were before this change rather than a new one. One thing to watch on the first dependabot run: upstream carries monorepo tags such as materialize-monitoring/v0.21.0 alongside the vX.Y.Z releases, and mixed tag namespaces on one repo have caused redundant PRs before (dependabot/dependabot-core#4616).

🤖 Generated with Claude Code

[bobbyiliev]

As we discussed during the cloud sync yesterday, pinning this and setting up dependabot.