Faire passer le seed par la connexion d amorçage

Le seed installe un premier compte de démonstration : il ne peut pas le
créer dans un contexte locataire qui n existe pas encore. Or il se
connectait avec le rôle applicatif, soumis à la row-level security en
FORCE — l upsert Prisma (INSERT ... ON CONFLICT) se heurtait à la politique
de lecture « id = planflow_current_account() », renvoyant NULL.

Utiliser ADMIN_DATABASE_URL (compte d amorçage), comme le fait déjà le
harnais de tests d intégration (tests/integration/admin-db.ts).

prisma/seed.ts

@@ -35,8 +35,18 @@ import { withTenant } from '../src/server/tenant';
 
 const DEMO_PASSWORD = 'planflow-demo-2026';
 
+// Connexion d'amorçage, **pas** celle de l'application — même principe que le
+// harnais de tests (tests/integration/admin-db.ts).
+//
+// L'application se connecte avec un rôle soumis à la row-level security, qui
+// ne voit rien hors du compte courant et ne peut pas créer de compte de toutes
+// pièces : c'est exactement ce qu'on attend de lui. Le seed, lui, installe un
+// **premier** compte de démonstration — il ne peut pas le faire dans un
+// contexte locataire qui n'existe pas encore. Il passe donc par la connexion
+// d'amorçage, comme un exploitant depuis le serveur.
 const adapter = new PrismaPg({
-  connectionString: process.env.DATABASE_URL ?? '',
+  connectionString:
+    process.env.ADMIN_DATABASE_URL ?? process.env.DATABASE_URL ?? '',
 });
 const prisma = new PrismaClient({ adapter });