Réparer l'intégration continue, et poser des ports internes non communs

**Le test des heures ne pouvait que tomber.** Il interrogeait le mois
précédent, alors que le seed ne pose que deux semaines : la courante et la
précédente. Hors des premiers jours d'un mois, le mois précédent est donc
vide. Mesuré sur une base semée à neuf : un seul mois porte des créneaux,
le mois courant. Le défaut ne se voyait pas en développement, où la base
garde les créneaux des exécutions antérieures — 39 créneaux de juillet
survivaient chez moi à des semis d'il y a plusieurs semaines.

**Le seed ne remettait pas l'état de publication.** Son `update` était vide,
si bien qu'une semaine déjà semée gardait le statut qu'elle avait alors : la
semaine précédente, publiée par définition, restait en brouillon dès qu'elle
avait été semée du temps où elle était la semaine courante. D'où des tests
qui échouent en local et passent en intégration continue — l'écart le plus
coûteux à diagnostiquer. Le statut est désormais réimposé.

**Ports internes.** L'application écoute sur 9317 et la base sur 5439,
jusque dans l'image. Sur un réseau Docker deux conteneurs peuvent écouter le
même port sans se gêner — ce n'est donc pas une correction de collision —
mais une valeur unique de bout en bout lève l'ambiguïté quand plusieurs
piles cohabitent derrière le même proxy, et la configuration du
reverse-proxy porte partout le même nombre. Publication, sonde de santé,
serveur, chaîne de connexion et scripts d'amorçage sont alignés sur une
seule variable par service.

`pnpm verify` : 450 tests. Playwright : 77/77 après remise à zéro du semis.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Cr9dkEHwbDgkWPnyGj1Rjv

docker/bootstrap-role.mjs

@@ -22,7 +22,10 @@ const superUser = process.env.POSTGRES_USER ?? 'planflow';
 const superPassword = process.env.POSTGRES_PASSWORD ?? '';
 const database = process.env.POSTGRES_DB ?? 'planflow';
 const host = process.env.POSTGRES_HOST ?? 'db';
-const port = Number(process.env.POSTGRES_PORT_INTERNAL ?? 5432);
+// Le port d'écoute **dans** le conteneur de la base, que la pile choisit peu
+// commun. Le défaut suit celui du compose, pas celui de PostgreSQL : une
+// valeur qui diverge se solderait par un refus de connexion à l'amorçage.
+const port = Number(process.env.POSTGRES_PORT_INTERNAL ?? 5439);
 
 const appRole = process.env.APP_DB_USER ?? 'planflow_app';
 const appPassword = process.env.APP_DB_PASSWORD ?? 'planflow-app-interne';

docker/init-app-role.sh

@@ -28,7 +28,9 @@ DB_USER="${POSTGRES_USER:-planflow}"
 # Dans le conteneur `db`, l'hôte est local ; depuis `db-init`, c'est `db`.
 # L'un et l'autre doivent aboutir au même SQL.
 if [ -n "${PGHOST:-}" ]; then
-  set -- -h "$PGHOST" -p "${PGPORT:-5432}" -U "$DB_USER" -d "$DB_NAME" -v ON_ERROR_STOP=1
+  # Défaut aligné sur celui de la pile, et non sur celui de PostgreSQL : la
+  # base écoute un port peu commun, et 5432 ne joindrait rien.
+  set -- -h "$PGHOST" -p "${PGPORT:-5439}" -U "$DB_USER" -d "$DB_NAME" -v ON_ERROR_STOP=1
 else
   set -- -U "$DB_USER" -d "$DB_NAME" -v ON_ERROR_STOP=1
 fi