Add least-privilege OIDC delivery for website infrastructure

Parent epic: #9

Normative spec: 08 — State and continuous delivery

Follow-up to the one-time audited local sandbox bootstrap in #70. This issue is non-blocking for that first sandbox deployment, but it is mandatory before repeated sandbox infrastructure changes or any production website plan/apply.

Scope

Implement a reviewable GitHub Actions Terraform plan/apply path in the private DataTalksClub/aws-infra repository, whose immutable repository identity is DataTalksClub@72699292/aws-infra@1279267530.

• Manage dedicated GitHub OIDC trust and least-privilege AWS IAM for website infrastructure separately from the application publisher/deployer roles in #69.
• Use a read-oriented plan boundary and a protected apply boundary. Apply is main-only, environment-protected, serialized without cancellation, and cannot be triggered by pull_request or pull_request_target.
• Scope S3 state access to bucket datamailer-sandbox-817685572750-us-east-1-tfstate, key sandbox/website/terraform.tfstate, its native lock object, and the minimum prefix listing. Plan may read state and use only the lock operations it needs; apply alone may update the exact state object.
• Scope AWS resource permissions to the website module/root and documented create/read/update/delete operations. Deny unrelated shared authentication, hosted-zone ownership, other state, production, and application ECR/ECS release operations.
• Require Terraform >= 1.10, native S3 locking with use_lockfile=true, locked providers, format/validate/policy/mock tests, exact root/path filters, current-main source selection, a reviewed non-secret plan summary, environment approval, and post-apply inventory/plan convergence.
• Pin third-party workflow actions by immutable commit, use short-lived OIDC only, redact sensitive plan/state values, and retain auditable run metadata without uploading state, secret values, backend credentials, or an unredacted binary plan.
• Document break-glass recovery, role ownership, permission changes, state locking, failed-apply recovery, and production instantiation with a separate account/backend/environment/trust boundary.

Non-goals

• No infrastructure apply, import, state move, production setup, application image publication/deployment, secret-value population, or broad shared-infrastructure role in this issue.
• Do not reuse phone-aws-sandbox-role as the automation role and do not grant either #69 application role Terraform, IAM, DNS, database, KMS, edge, or state mutation.

Acceptance criteria

• Terraform defines dedicated aws-infra OIDC plan/apply trust using immutable owner/repository identity, exact audience and ref/environment claims, with negative tests for mutable names, wildcard subjects, forks, PRs, tags, feature branches, wrong environments, IDs, and audiences.
• Plan and apply permissions are separated and least privilege; exact state/key/lock access is enforced, unrelated state/shared resources are denied, and no long-lived AWS credential exists.
• The workflow uses Terraform >= 1.10 and native S3 locking, runs all repository gates, selects trusted current main, shows a redacted reviewable plan, requires protected approval for main-only apply, and serializes applies without cancellation.
• Application publisher/deployer roles cannot invoke the infrastructure workflow, assume its roles, mutate Terraform state, or apply infrastructure; policy tests prove those denials.
• A no-op sandbox rehearsal proves exact identity, state locking, reviewed-plan/apply provenance, post-run inventory, and terminal plan convergence without exposing secrets or mutating unrelated resources.
• Production documentation requires a separate account/backend/environment/trust configuration and blocks production website infrastructure work until this issue is accepted.

Test scenarios

1. Exercise the complete trust-claim matrix and environment branch protection; only the intended aws-infra main/environment subjects can assume their matching roles.
2. Attempt cross-role, unrelated-state, unrelated-zone/resource, application-release, shared-auth, IAM-escalation, and production operations; each is denied.
3. Run format, validate, static policy, mock plan, Terraform-version, provider-lock, state-key, path-filter, and action-pin checks; each fails closed when deliberately violated.
4. Start concurrent applies and prove only one may mutate while a running apply is never cancelled; verify lock cleanup and documented recovery after an injected failure.
5. Rehearse a reviewed no-op sandbox apply and prove the same trusted main revision, exact root, approved plan, post-apply inventory, and terminal no-change plan are recorded without secret/state artifacts.

Dependencies

• Follows #67–#70 and may reuse their accepted website module/root and ownership inventory.
• Non-blocking for the explicitly one-time local first sandbox apply in #70.
• Blocks repeated sandbox website infrastructure mutations and any production website Terraform plan/apply.

Start with _docs/specs/08-aws-sandbox-terraform.md and the accepted website module/root and ownership inventory from #67–#70, then inspect the aws-infra repository. Use the listed trust, permission, workflow, policy, and rehearsal test scenarios as the validation plan. Done means least-privilege plan/apply paths, protected approval, auditable redacted runs, successful no-op convergence, and production-boundary documentation.