refactor(ci): deduplicate deploy workflows

[cqnykamp]

Stacked on #3007 — this branch includes that PR's commits; the diff shrinks to just the refactor once #3007 merges.

Summary

The three deploy entry points (dev-deploy.yml, dev-deploy-pr.yml, prod-deploy.yml) each repeated two things:

1. The backend/frontend/site fan-out, ~40 lines of per-environment constants per caller (account IDs, role ARNs, ECR repo, cluster, SNS topic, tag).
2. The GitHub deployment bookkeeping bash (open + finalize), six near-identical blocks that had already drifted between copies (lights-out handling in dev, production_environment badge in prod).

No behavior change intended for any entry point.

Changes

• reusable-deploy-env.yml — the single definition of what "a deploy" is. Takes deploy_ref + env_name, resolves all per-environment constants in one config job (the only place the two AWS accounts are named), fans out to the three existing component workflows, and exposes backend_result / frontend_result / site_result as outputs. Callers shrink to trigger/gate logic plus one deploy job. Adding a component or a smoke-test to "a deploy" is now a one-file edit.
• .github/actions/open-deployment — opens a deployment record and marks it in_progress. Best-effort: never fails the job; empty deployment_id output means "no record, skip finalize". production-environment input covers prod's badge.
• .github/actions/finalize-deployment — sets the final status from the three component results. The dev-only lights-out logic became an optional lights-parameter input: when set, a successful deploy while the environment is asleep is recorded as inactive; when unset (prod), plain success/failure. Any SSM read failure degrades to "treat as awake", which matches the old HAVE_AWS fallback.

Notes for review

• Local composite actions require the repo on disk, so the bookkeeping jobs gained actions/checkout steps. In dev-deploy-pr.yml the checkout is conditioned on actually deploying, and issue_comment checks out the default branch, so the gate still never runs PR-controlled code.
• Nesting depth is caller → deploy-env → component, within GitHub's 4-level reusable-workflow limit.
• The status descriptions are now generated from the environment name (deployed to prod / dev3 deploy failed (backend:… frontend:… site:…)), matching the previous per-copy strings.
• dev-deploy-pr.yml runs from the default branch on issue_comment, so its changes only take effect after merge. The push/dispatch paths can be exercised beforehand via gh workflow run dev-deploy.yml on this branch.

🤖 Generated with Claude Code