the ha first boot still restarts one replica: both race to create schema_migrations

[lex00]

After the cnpg wait (#86) the first boot at ha is down from two-three restarts per replica to exactly one, on one replica, on a brand-new database: both replicas reach a virgin Postgres together and race to create Ecto's schema_migrations table. The advisory lock serializes migrations only once that table exists, so the loser exits on the unique-constraint error and its retry wins. Benign, and precisely documented in Make it durable — but a clean boot would be better than a well-documented dirty one.

The clean fix is structural: migrations run once, in a Job (or a single elected pod), and the app pods wait for them instead of each running their own. fountain migrates at boot unconditionally, so this needs an upstream switch to skip migrations at app boot — file that against fountain when this is picked up. Until then this issue records why RESTARTS 1 can appear once and never again.

[lex00]

Upstream issue draft, ready to file against fountain (decided here first: draft-only, filed by a human when chosen):

---

Title: an env switch to skip boot-time migrations, so a deployment can run them once in a Job

fountain migrates at boot, on every replica, before the endpoint listens. For single-replica deployments that is exactly right. At two or more replicas on a brand-new database it races itself: Ecto's advisory lock serializes migrations only once schema_migrations exists, and creating that table is the race — both replicas reach a virgin Postgres together, the loser exits 1 on the unique-constraint error (pg_type_typname_nsp_index for the schema_migrations type), Kubernetes restarts it, the retry wins. Observed reproducibly standing up a 2-replica deployment against a fresh CNPG database: RESTARTS 1 on one replica, every first boot.

The restart is benign but indistinguishable at a glance from a crash-looping deployment, and the standard Kubernetes shape — migrations in a Job, app pods that only serve — is currently impossible because the release migrates unconditionally.

The ask: an environment switch (SKIP_MIGRATIONS=true, or MIGRATE_ON_BOOT=false) that makes the release skip the boot-time migration path, so a deployment can run Fountain.Release.migrate/0 (or equivalent) once, in a Job, and scale the app freely. Default unchanged — single-replica boots keep migrating exactly as today.

---

Context for this repo: with the switch, tier=ha gains a migrations Job and loses its last first-boot restart; without it, the docs describe the restart precisely (Make it durable) and this issue stays open.

[lex00]

Filed upstream as BinaryBourbon/fountain#610. This issue unblocks when that lands: the clean fix here is a migrations Job plus the app pods booting with the new switch, and the last first-boot restart at ha goes away.