R1.1 Relay production environment

Mirrors issue R1.1 Relay production environment from the DataTalksClub/community-base unification plan (docs/plan/phase-1.md). Repository: DataTalksClub/relay (code) and DataTalksClub/aws-infra (Terraform, by pull request). Depends on: nothing.

Goal

Give Relay a production deployment path: a manually approved production deploy workflow, the production tenant provisioning for the first client (the DTC website), and operator documentation. The plan issue's live checks (canary email, SES identity in the AWS console, prod system.echo) are owner-gated and stay open after the code lands.

Scope

1. deploy-prod.yml: a workflow_dispatch production deploy workflow gated on the production GitHub environment with a required reviewer. It reuses scripts/deploy_relay_sandbox.sh parameterised by --environment production; sandbox behaviour of the script is unchanged.
2. scripts/provision_production_tenant.sh: provisions organisation datatalksclub, audience dtc, client dtc-website, default sender DataTalks.Club <hello@datatalks.club> (final address to be confirmed by the owner in the pull request), and one client API key. The key is generated on the host into the 0600 runtime env file, following the sandbox RELAY_BOOTSTRAP_API_KEY mechanism; the script never prints or embeds key material. The owner copies the key into the DTC deployment secrets.
3. docs/production.md: the production environment, on-call checks, and rollback. Explicit that production is not deployed yet.

Note on the Terraform half

The plan's aws-infra step (a production Relay root) is already satisfied by the merged main/relay root in DataTalksClub/aws-infra, with documented deviations from the issue text (no Elastic IP: the host is private behind the shared ALB; one ingress queue: the inbound path is deliberately out of scope; the datatalks.club SES identity, DKIM, SPF and DMARC records live in main/common and main/website-static). That conflict is reported to the plan owner as a plan fix; nothing is applied.

Acceptance criteria

• deploy-prod.yml deploys only on manual dispatch from main, only after lint/checks/tests pass, and only after the environment reviewer approves.
• Sandbox deploy path of scripts/deploy_relay_sandbox.sh is byte-for-byte behaviour-identical.
• The provisioning script has a dry-run mode and never prints key material.
• docs/production.md states production is not deployed and lists the owner-gated checks.

Test notes

• uv run pytest (full suite), uv run ruff check ..
• python -c yaml.safe_load on both workflows.
• bash -n and --help/--dry-run for both scripts.
• Live checks (curl system.echo against prod, /internal/ops/status, SES identity verified in the console) need the owner to apply the Terraform pull request and run the prod deploy: Not run here, needs: owner approved and applied the Terraform root and the first production deploy.

Read the scope for deploy-prod.yml, scripts/deploy_relay_sandbox.sh, scripts/provision_production_tenant.sh, and docs/production.md first. Run uv run pytest, uv run ruff check ., yaml.safe_load on both workflows, and bash -n with --help/--dry-run for both scripts. Done means the manual, reviewer-gated deployment, safe dry-run provisioning, and owner-gated production documentation checks are in place; live checks require the owner.