Bump dflook/terraform-plan and terraform-apply from v1 to v3 in incubator's Terraform workflows

### Overview

We need to move `dflook/terraform-plan` and `dflook/terraform-apply` off `@v1` in incubator's two Terraform workflows, because the v1 line stopped receiving fixes in May 2025 and is missing correctness fixes shipped since — including one where `terraform-apply` wrongly decides the plan changed and aborts. These two pins were missed entirely by the org's third-party action sweep, which is why they have no ticket until now.

### Action Items

- [ ] Read the caveat under Resources/Instructions before starting. Merging this PR triggers a real `terraform apply` against the production AWS account, which is not true of most workflow-file changes.
- [ ] In `.github/workflows/terraform-plan.yaml`, change `uses: dflook/terraform-plan@v1` to `@v3` (line 41 when written; find it by the `uses: dflook/terraform-plan` line if it has drifted).
- [ ] In `.github/workflows/terraform-apply.yaml`, change `uses: dflook/terraform-apply@v1` to `@v3` (line 41 when written; same fallback).
- [ ] Change nothing else in either file. The three inputs in use — `path` and `backend_config_file` in both, plus `auto_approve` in apply — all still exist at v3.0.0 with the same names and meanings, so their lines stay exactly as they are.
- [ ] Open the PR. Because both workflows filter on `paths: ['**/*.tf', '**/*.yaml']` and the workflow files are themselves `.yaml`, **the PR will trigger the `Terraform plan (OIDC)` job against your branch** — so the new pin gets exercised before anything merges. Do not merge until that job has run.
- [ ] Confirm the `Terraform Plan` step **succeeded**. If it fails during provider initialisation rather than during the plan itself, read "What to watch" below before trying another version — that failure has a specific likely cause.
- [ ] Confirm the posted Terraform plan reports **no resource changes**. This PR touches no `.tf` files, so any proposed create/update/destroy means either something has drifted or the action behaves differently at v3 — do not merge a non-empty plan, and report what it proposed on this issue instead.
- [ ] **After the PR merges**, open the Actions tab and confirm the `Terraform apply (OIDC)` run triggered by the merge **succeeded** and made no resource changes. The merge to `main` fires this automatically. This step cannot be done from the branch, and it is the only place the apply action gets exercised at all — the PR only ever runs the plan action.
- [ ] **After the PR merges**, comment on this issue with links to the plan run and the apply run, so the verification is on the record.

### Resources/Instructions

**Files to change** (both in `hackforla/incubator`, branch `main`):

- `.github/workflows/terraform-plan.yaml`
- `.github/workflows/terraform-apply.yaml`

**What `@v1` actually resolves to.** `@v1` is a floating major tag, so these workflows are not running the 2021 release — they are on **v1.49.0 (2025-05-29)**, the last release on that line. The maintained line has moved on twice since: v2.0.0 (2025-05-31) and v3.0.0 (2026-07-18). So this is a "we are missing bug fixes" bump, not a "this breaks next month" one.

Fixes released after v1.49.0 that these workflows do not have:

| Release | Fix |
|---|---|
| 2.2.1 | Misleading whitespace-only diffs reported when a plan is truncated for being too large for a PR comment |
| 2.2.2 | `terraform-apply` could wrongly conclude the plan had changed and abort, when the plan contained both imports and warnings |
| 2.2.3 | More than 8 `var_file` entries caused the action to fail |
| 3.0.0 | Wrong PR comment matched when a `backend_config` value contains an `=` character; plan lines containing `~` formatted incorrectly |

**The two breaking changes crossed, and why neither affects us:**

- **v2.0.0 removed the deprecated `var:` input** (deprecated back in v1.9.0, 2021). Neither workflow passes `var:` — checked both files, they use only `path`, `backend_config_file` and `auto_approve` — so this is a no-op here.
- **v2.0.0 and v3.0.0 each bumped the container base image** (debian 11 → 12 → 13). These are Docker actions (`runs: using: docker`), so this changes the runtime environment Terraform executes in. See "What to watch" below.

**Note this is a different call from `actions/checkout`.** These are Docker actions, so the Node 20 deprecation driving the rest of the org's action-bump work does not apply to them at all — nothing here is on a removed runtime. That is why this was safe to leave until now, and why it can go straight to current (`@v3`) rather than to a deliberately conservative intermediate version the way `actions/checkout` was held at v5.

**What to watch: the plan job talks to the production database.** `terraform/backend.tf` declares the `cyrilgdn/postgresql` provider with `sslmode = "require"`, and the plan job passes `TF_VAR_pghost` / `TF_VAR_pgpassword`, so this Terraform makes a real TLS connection to RDS from inside the action's container. A base-image change is the one thing in this bump that could plausibly disturb that (CA bundle, OpenSSL defaults). If the job fails at provider init or with a TLS/connection error rather than on the plan itself, that is the likely cause — report it here rather than working around it, since the same question will apply to devops-security when its pins are bumped.

Terraform's own version is not pinned to an exact release either (`terraform/backend.tf` line 2 sets `required_version = "~> 1.12"`), so the action resolves it at run time. That is equally true at v1 and v3, so this bump does not change it — but it is a second reason the empty-plan gate matters.

**Caveat — merging runs a production apply.** `terraform-apply.yaml` triggers on push to `main` with `paths: ['**/*.tf', '**/*.yaml']`. Because this PR edits `.yaml` files, merging it **will** start a `terraform apply` against AWS account `035866691871`. That is why the empty-plan check above is a hard gate rather than a formality.

**Out of scope, deliberately:** `hackforla/devops-security` pins the same two actions at `@v1` in its own `terraform-plan.yaml` and `terraform-apply.yaml` and needs the same bump. It is left out of this issue because that repo's workflows filter on `'**/*.tf'` only — a workflow-file-only PR there triggers neither plan nor apply, so the change cannot be verified the way this one can and needs its own approach.

**Also checked, and already current:** `terraform-docs/gh-actions@v1.4.1` in `terraform-plan.yaml` is the latest release of that action. It does not need bumping and is not part of this issue.

**Related:** [incubator#158](https://github.com/hackforla/incubator/issues/158) bumps `aws-actions/configure-aws-credentials` in the same two files — if both are open at once, sequence them rather than stacking them, so a failed plan points at one change. [incubator#156](https://github.com/hackforla/incubator/issues/156) / [incubator#157](https://github.com/hackforla/incubator/pull/157) removed `bastion.yml`, which held other out-of-date pins from the same sweep. [devops#183](https://github.com/hackforla/devops/issues/183) covers `actions/checkout` across the org and explicitly excludes third-party actions like these.

Read the caveat and resources first, then inspect .github/workflows/terraform-plan.yaml and .github/workflows/terraform-apply.yaml at the dflook action pins. Run the branch's Terraform plan workflow and confirm the Terraform Plan step succeeds with no resource changes; after merge, verify the apply run also succeeds with no changes and record both run links on the issue.

Written by the indexing model from the issue text.