story: CI/CD pipeline for staging and production

[GitAddRemote]

User Story

As a platform maintainer,
I want an automated CI/CD pipeline that deploys to staging and promotes to production only after approval,
So that releases are repeatable, auditable, and safe.

Context

The repo is a pnpm monorepo with a NestJS backend and React frontend. CI is already present for backend/frontend, but deploy is placeholder-only.

Definition of Done

• A single, main-branch CI/CD workflow builds, tests, and publishes artifacts/images for backend and frontend.
• Staging deploy runs automatically on main after CI passes.
• Production deploy is gated behind environment approval and only runs after staging succeeds.
• Environment-level secrets for staging/production are documented (kubeconfig, registry access, etc.).
• Helm charts/values are in-repo and parameterized for environment/image tags.
• Documentation is added/updated for setup and rollback guidance.
• PR CI remains intact for lint/typecheck/tests/build on changed packages.

Technical Elaboration

• Consolidate or update GitHub Actions workflows to:
  • Run backend lint/unit/e2e/build and frontend lint/typecheck/build.
  • Build and push backend/frontend images to GHCR (or chosen registry) tagged by commit SHA and main.
  • Deploy to staging using Helm with a dedicated environment.
  • Deploy to production only after manual approval via GitHub Environments.
• Add Helm charts for backend and frontend (deployment/service/ingress) with values files for staging/production.
• Add a deployment script (e.g., scripts/deploy/helm-deploy.sh) to standardize Helm upgrades with image tags.
• Add docs/cicd.md describing required secrets, image naming, and environment configuration.
• Validate that the pipeline does not run on PRs (PRs only run CI checks).

Notes

• If registry or k8s provider differs, adapt the workflow accordingly.
• Confirm whether migration workflows should be integrated or remain manual.