Faire poser le rôle applicatif par l'application elle-même

`db-init` suppose un orchestrateur qui honore
`depends_on: service_completed_successfully`. Swarm l'ignore, et une pile
déployée avant l'ajout du service ne le contient même pas. L'application
redémarrait alors en boucle sur un refus d'authentification que le
diagnostic ajouté précédemment décrivait sans que personne puisse le
corriger.

Elle le corrige donc elle-même au démarrage, si on lui confie les
identifiants d'amorçage — et se tait sinon, pour ne pas contrarier un
déploiement qui préfère les garder hors du conteneur applicatif. Le point
d'entrée retire ces variables avant de lancer le serveur : le processus qui
sert les requêtes ne les voit jamais.

Le branchement create/alter se fait côté client et non dans un bloc `DO` :
le corps d'un `DO` est une chaîne littérale, où `$1` n'est pas un paramètre
de requête. L'échappement du mot de passe est confié à `quote_literal`, et
le nom de rôle est refusé s'il n'a pas la forme d'un identifiant.

Éprouvé sous authentification scram réelle : après réalignement, l'ancien
mot de passe est refusé et le nouveau accepté, le rôle reste NOSUPERUSER
NOBYPASSRLS et devient propriétaire de la base.

Au passage, `withTenant` pose un budget de transaction explicite. Tout accès
aux données passe par lui, si bien que le défaut Prisma de 5 s plafonnait en
réalité chaque requête de l'application, et l'échec se présentait en `P2028`
qui ne désigne ni la requête ni la cause.

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

docker-compose.yml

@@ -105,8 +105,17 @@ services:
       # salarié écrites dans la couche du conteneur disparaîtraient au premier
       # redéploiement, et une pièce d'identité perdue ne se reconstitue pas.
       DOCUMENT_STORE: /data/documents
-      # Sert uniquement au diagnostic affiché quand la connexion est refusée.
+      # Amorçage du rôle applicatif depuis le conteneur, pour les
+      # orchestrateurs qui n'honorent pas `depends_on` — Swarm, notamment — et
+      # pour les piles déployées avant l'ajout de `db-init`. Le point d'entrée
+      # retire ces variables avant de lancer le serveur : le processus qui sert
+      # les requêtes ne les voit jamais.
+      POSTGRES_USER: ${POSTGRES_USER:-planflow}
+      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:-planflow-interne}
+      POSTGRES_DB: ${POSTGRES_DB:-planflow}
+      POSTGRES_HOST: db
       APP_DB_USER: ${APP_DB_USER:-planflow_app}
+      APP_DB_PASSWORD: ${APP_DB_PASSWORD:-planflow-app-interne}
     volumes:
       - documents:/data
       # Volume distinct de la base et des documents : sauvegarder l'un ne doit