Only auto-approve the Terraform apply on workflow_dispatch

[ale210]

Closes #187.

On a push to main the apply no longer approves its own plan. dflook/terraform-apply finds the pull request the pushed commit came from, reads the plan comment posted on it, and re-plans — applying only if the new plan is logically the same, and failing with plan-changed if it has drifted. What reaches production is then the plan a reviewer actually saw.

workflow_dispatch is new here and keeps auto_approve: true, because there is no pull request on that path and so no plan to match against. It exists as the recovery route: when a merge-triggered apply fails plan-changed, re-running it from the Actions tab replays the same push event and fails identically, so without a manual trigger there is no way back at all.

That dispatch path is the unreviewed one, and what makes it safe is #182. devops-security-tf-apply conditions its sub on refs/heads/main only, so a dispatch from any other branch presents a different sub and AWS refuses the AssumeRole outright. This change was deliberately blocked on that work — under the static keys it replaced, which carried no branch scoping, the same trigger would have been an unreviewed apply runnable from anywhere. terraform/aws-gha-oidc-providers.tf now records that the narrowness of that condition is load-bearing, so nobody widens it to refs/heads/* without realising what it switches on.

Verified before making the change:

• The apply job authenticates with role-to-assume: …/devops-security-tf-apply, confirmed on main, which is action item 1 on the issue.
• pull-requests: write and GITHUB_TOKEN are both already present. Neither needed adding, but the action uses them to read the plan comment, so this change is what makes them load-bearing rather than incidental.
• push is a documented trigger for auto_approve: false in the pinned v1; workflow_dispatch is not, which is why that path keeps true.

Why there is a Terraform change in a workflow pull request. Both workflows filter on paths: ['**/*.tf'], so a pull request touching only workflow files triggers neither, and this would sit unexercised until somebody else's Terraform change landed. The note above is itself a .tf change, so the plan runs here and the apply runs on merge.

Two new ways a merge can fail, worth saying out loud rather than discovering:

• A pull request can merge with the plan job failed or never run — main requires a review but has no required status checks — and that now produces a failed apply instead of a silent auto-apply. Making the plan a required check is the natural follow-on and is not done here.
• A direct push to main has no originating pull request and therefore no plan comment, so it will fail. Recovery is workflow_dispatch.

Do not read a green run as proof the gate works — check which branch it took. In the action's apply.sh the condition is if [[ "$INPUT_AUTO_APPROVE" == "true" || $PLAN_EXIT -eq 0 ]], and PLAN_EXIT of 0 is Terraform's "no changes" code, so a no-op plan is applied without ever comparing against the pull request comment. The log then reads auto_approve: false followed by Automatically approving plan, which looks like the change failed and has not. Expect exactly that here, since this pull request changes no infrastructure. The first pull request that changes real IAM configuration is the true first exercise of the comparison.

[github-actions]

Terraform plan in terraform
With backend config files: terraform/prod.backend.tfvars

No changes. Your infrastructure matches the configuration.

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration
and found no differences, so no changes are needed.

✅ Plan applied in Apply Terraform changes on merge #44