Rendre le déploiement Docker correct, et la RLS réellement active

Trois problèmes, dont un grave, trouvés en corrigeant un échec de déploiement.

**Le compose connectait l'application en superutilisateur PostgreSQL.** Un
superutilisateur contourne toute politique de sécurité au niveau ligne, y
compris déclarée en FORCE : la seconde couche d'isolation était présente en
base et absente des faits. Le README l'interdisait déjà noir sur blanc ; le
chemin de déploiement que nous livrons faisait exactement l'inverse. Un script
d'initialisation crée désormais un rôle `planflow_app` NOSUPERUSER NOBYPASSRLS,
propriétaire de la base — il lui faut ce droit pour migrer, et les politiques
sont en FORCE précisément pour s'appliquer aussi au propriétaire. Mesuré : en
superutilisateur, deux lignes visibles sans compte courant ; avec le rôle
dédié, zéro.

Basculer la base de développement sur ce même rôle a révélé le défaut que le
superutilisateur masquait : `resolveSession` lisait `Membership`, table filtrée
par compte, sans périmètre. Avec la RLS active, plus personne ne pouvait se
connecter. La résolution passe maintenant par une porte étroite — une politique
qui n'ouvre que les lignes dont l'utilisateur est titulaire, sous `app.user_id`
— le temps de trouver le compte, puis repasse par le périmètre ordinaire. La
suite de tests traverse enfin la RLS au lieu de la contourner.

**Les pièces du dossier salarié n'avaient aucun volume.** Elles étaient écrites
dans la couche du conteneur et disparaissaient au premier redéploiement. Une
pièce d'identité perdue ne se reconstitue pas.

Le reste répond à la demande : Postgres préconfiguré — la base n'étant ni
publiée ni attachée au réseau du proxy, ce mot de passe protège d'un conteneur
voisin, pas d'Internet — réseau `nginx_default` déclaré externe avec
l'application seule dessus, et port publié peu courant.

ENCRYPTION_KEY reste la seule variable sans valeur par défaut, et n'en aura
pas : elle chiffre le NIR, l'IBAN et les arrêts de travail. Une clé livrée avec
l'image serait connue de quiconque lit ce dépôt.

Au démarrage, l'application contrôle ses propres privilèges : elle refuse de se
lancer si la base porte plus d'un compte, et se contente d'un avertissement
s'il n'y en a qu'un — bloquer une installation mono-compte fermerait l'accès de
l'entreprise à ses données pour une fuite entre clients qui ne peut pas se
produire.

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

src/server/tenant.ts

@@ -131,10 +131,36 @@ export async function withTenant<T>(
   });
 }
 
+/**
+ * Exécute `fn` au nom d'un utilisateur, **avant** que son compte soit connu.
+ *
+ * Sert au seul amorçage de session : trouver à quel compte un utilisateur
+ * appartient suppose de lire son rattachement, et le rattachement est
+ * lui-même filtré par compte. Sans cette porte étroite, la seule issue serait
+ * de connecter l'application avec un rôle qui contourne la RLS — c'est-à-dire
+ * de la désactiver partout pour résoudre un cas d'amorçage.
+ *
+ * La politique associée n'ouvre que les lignes dont l'utilisateur est le
+ * titulaire (voir la migration `membership_self_read`).
+ */
+export async function withUser<T>(
+  userId: string,
+  fn: (db: ScopedClient) => Promise<T>,
+): Promise<T> {
+  return prisma.$transaction(async (tx) => {
+    await tx.$executeRaw`SELECT set_config('app.user_id', ${userId}, true)`;
+    return fn(tx as unknown as ScopedClient) as Promise<T>;
+  });
+}
+
 /**
  * Accès sans portée de compte, pour les opérations qui précèdent l'identité :
  * authentification par e-mail, acceptation d'invitation, migrations.
  *
+ * Ne donne accès qu'aux tables **sans** colonne `accountId` — sessions,
+ * utilisateurs, codes de secours. Les autres restent filtrées par la RLS, qui
+ * ne laisse rien passer hors d'une transaction scopée.
+ *
  * Volontairement nommé pour se voir en revue de code.
  */
 export function unscoped(): PrismaClient {