RV-S1: Terraform / deployer / entrypoint disagree on production DB name and owner #172

What happened

External repository review at commit c7bebd1 found a three-way disagreement between the production deployment artefacts. Static read, not reproduced against a live Azure deploy.

Also: a freshly built migration image contains only the committed example launchers. The entrypoint expects a concrete env_prod.sql that nothing in the image generates. A clean image can therefore fail before deployment, even before the name mismatch comes into play.

Why this matters

Two separate problems:

1. Clean-image failure. A fresh production image (first deploy, or disaster-recovery rebuild) cannot start because env_prod.sql is absent and nothing generates it.
2. Config drift between IaC and runtime. Terraform creates te_prod owned by pgadmin. Deployer uses te_mgmt_prod owned by postgres. Running both against a fresh server leaves either two databases, a missing one, or an owner mismatch depending on order.

No production deployment exists yet (#31, #32, #34 all open on Azure setup / cert errors), so nothing is broken today. The hazard is: when Azure plumbing is resolved and the first deploy runs, this breaks before the service starts, with a cryptic entrypoint error.

Decision taken 3 Nov 2026

Fix all three artefacts together in one PR, with a fresh-image fresh-server test as evidence. Splitting the fix leaves the system individually broken at each intermediate state. Must land before Azure plumbing (#31, #32, #34) resumes, so the first production deploy doesn't hit it.

Sub-decision still open: canonical name

Needs the product owner's call before the fix lands:

• (a) te_prod owned by pgadmin — match Terraform-as-source-of-truth, standard IaC convention
• (b) te_mgmt_prod owned by postgres — match the deployer, keeps whatever intent "mgmt" was conveying

Running the app as postgres (superuser) is poor practice regardless; if the real intent was "deployer creates DB as postgres, then grants to pgadmin", option (a) with a grant step is the right shape.

Proposed

Three parts in one PR:

1. Choose canonical name (sub-decision above).
2. Make the entrypoint self-sufficient. Preferred approaches:
   • Generate env_prod.sql at runtime from a template committed to the image
   • OR make the entrypoint tolerant of its absence and generate from connection env vars
   • NOT: commit a populated env_prod.sql to the image, as that risks baking secrets (see RV-S4 / #G37)
3. Align Terraform, deployer and entrypoint on the chosen name and owner.

Done when

• One canonical name and owner across all three artefacts, referenced in DECISIONS/<date>-prod-db-naming.md.
• Fresh-image fresh-server verification: build image from a clean checkout, run against a PostgreSQL server with no pre-existing pgadmin or postgres role beyond the superuser, confirm clean startup.
• The verification is recorded on the PR with the exact command and its output.
• CI replica run quoted on the PR (counts in passed / failed / skipped form).

Reference

Tracker row G34 (main tab). Repo review finding RV-S1. Related: G37 (RV-S4 secrets in image), G36 (RV-S3 shared role across environments) — all Standards P1 touching deployment safety. Blocks: nothing today; must land before Azure plumbing (#31, #32, #34) resumes.