chore(terraform): refine state lock semantics (skip on plan, wait on apply)

[olepg]

Refine how the reusable terraform.yml workflow interacts with the state lock.

terraform plan: -lock=false

terraform plan is read-only against state and does not need to acquire a lock. Taking one blocks concurrent plans from other PRs (or other working directories sharing the same backend) for no benefit. Skipping the lock lets plan runs proceed in parallel.

terraform apply: new lock_timeout_minutes input (default 0)

By default terraform apply fails immediately if the state lock is held. With concurrent applies queued via the workflow's concurrency group this is rarely an issue, but transient contention from external tooling (manual terraform apply runs, drift-detection jobs, etc.) can sometimes cause spurious failures.

Added a new lock_timeout_minutes input (number, default 0) that is passed to terraform apply as -lock-timeout=<N>m. When set to 0 the flag is omitted entirely, preserving Terraform's native fail-fast behavior — so the default is a no-op for existing consumers. Consumers that hit lock contention can opt into waiting (e.g. lock_timeout_minutes: 20).

This input change is additive; existing consumers do not need to update anything.

Split out from #993.

---

Caveat on -lock=false

To be upfront: HashiCorp explicitly warns against -lock=false ("dangerous if others might concurrently run commands against the same workspace"), so this is a real trade-off, not a free win. Worth being explicit about the actual race scenarios:

1. External actor also bypasses locking. Anything that writes state without holding the lock — terraform apply -lock=false from a laptop, terraform state rm/mv/push -lock=false, custom scripts uploading state directly to the backend, or misconfigured wrappers that pass -lock=false by default. Possible but rare; most tooling locks by default.
2. External actor holds the lock and is mid-apply. With -lock=true (default), our plan would block waiting for their lock, then read consistent post-apply state. With -lock=false, our plan reads the pre-apply snapshot while their apply is still in flight; they then finish and bump the state serial. Our plan now references a state version that no longer exists.

In both cases terraform apply <planfile> validates the saved plan's state lineage/serial against current state and normally refuses to apply a stale one, so the usual failure mode is a failed apply (re-run required), not a silent wrong apply. The check is lineage/serial only, not a full semantic diff, so narrow edge cases involving data source reads can still slip through. Plans also go stale on their own within hours regardless of locking.