chore(terraform): terraform security hardening

[olepg]

Two small, independent hardening changes to the reusable terraform.yml workflow.

1. Stop leaking ENCRYPTION_PASSWORD to every step

Removed ENCRYPTION_PASSWORD from the workflow-level env: block and scoped it to only the two steps that actually need it (Create tarball in the plan job, Extract tarball in the apply job).

Secrets passed via secrets: to a reusable workflow are auto-masked by GitHub. Promoting them to a workflow-level env: widens exposure to every step (including any third-party actions added later) with no benefit. The secret's description was updated to note this.

2. Make plan-tarball retention configurable (default 5 days, was 35)

Added a new artifact_retention_days input (number, default 5) and use it for retention-days on the Upload artifact step.

The artifact contains the full Terraform configuration and plan, encrypted with ENCRYPTION_PASSWORD. It is only consumed by the Apply job in the same workflow run. 35 days of retention is unnecessary exposure window if the password ever leaks. Making it an input lets consumers tune the value to their deployment cadence (e.g. workflows that span multiple environments over several days can opt for a higher value).

This is an additive input change — existing consumers get the new 5-day default automatically without any code changes.

---

The lock-semantics change originally proposed here has been split out into #997.

[sefornes]

@olepg Sensible changes, though I'm not entirely certain on change no. 2.
Keeping the tarball for only one day requires you to deploy to all environments within 24h. For most cases this would be enough, but for some changes you might need to test those changes for more than 24h.

@equinor/ops-actions-maintainers Opinions?

[olepg]

@sefornes From my experience, terraform plans will go stale within a few hours, so they are useless in the following days regardless.
Though, in the times I've experienced stale plans, I haven't bothered to investigate why. I do not think plans have an expiry date.

I'm happy to change the timeout to a few days if you feel that is more suitable. 35 is overkill.

[helenakallekleiv]

I agree with @sefornes on change nr. 2, in my experience I've had to keep the tarball for more than 24h. I've also havent had any issues with the changes going stale, allthough I can agree that 31 days might be excessive. We do have a planning session today where we can discuss this and find a sensible number.

[olepg]

Happy to join the session if you want input.

[olepg]

2 make variable, default 5 days

3 make seperate pr