Créer le rôle applicatif à chaque démarrage, pas seulement au premier

Les migrations échouaient sur « Authentication failed for planflow_app ». Le
script qui crée ce rôle était monté dans /docker-entrypoint-initdb.d, lequel ne
s'exécute qu'à la **toute première** initialisation du volume : une pile dont le
volume existait déjà — créé par une tentative antérieure — n'a jamais vu passer
le rôle. Je l'avais noté dans le README au lieu de le traiter.

Un service `db-init` rejoue désormais le script à chaque démarrage, et le script
est rendu rejouable : il crée le rôle ou aligne son mot de passe, transfère la
propriété de la base, du schéma et des objets déjà présents. Les identifiants du
superutilisateur restent dans ce service ; les confier au conteneur applicatif
lui donnerait de quoi contourner la row-level security, ce que tout ce montage
cherche à empêcher.

Éprouvé sur une base créée par le superutilisateur, comme celle du client :
rôle posé en NOSUPERUSER NOBYPASSRLS, propriétaire de la base et des tables
préexistantes, capable de se connecter et d'exécuter du DDL ; les 22 migrations
s'appliquent ; la RLS le filtre — deux comptes visibles par le superutilisateur,
zéro par lui hors périmètre. Rejoué une seconde fois sans effet de bord.

Non vérifiable ici : l'authentification par mot de passe, mon cluster de
développement étant en mode `trust`.

Corrigé au passage une interférence entre tests : celui qui retire « Gérer les
rôles » aux rôles semés, pour atteindre le refus de verrouillage, s'exécutait en
parallèle de ceux qui s'appuient sur cette capacité et les faisait échouer par
intermittence. Le fichier passe en série.

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

tests/e2e/roles.spec.ts

@@ -9,7 +9,13 @@ import { slugifyRoleKey } from '../../src/domain/access/role-editing';
  * changement de code. » Le vérifier suppose d'aller jusqu'au bout : créer le
  * rôle, l'attribuer, et constater qu'un écran s'ouvre ou se ferme en
  * conséquence. Un test qui s'arrêterait à « la case est cochée » ne dirait rien.
+ *
+ * En série, et il le faut : l'un de ces tests retire momentanément « Gérer les
+ * rôles » aux rôles semés pour atteindre le refus de verrouillage. Joué en
+ * parallèle des autres, qui s'appuient sur cette même capacité, il les fait
+ * échouer par intermittence — et la cause n'est visible nulle part.
  */
+test.describe.configure({ mode: 'serial' });
 
 const OWNER_PASSWORD = 'planflow-demo-2026';