Ajoute la V1 fonctionnelle : upload invité, galerie admin, QR code, backend Supabase

Schéma dédié `photobooth` (jamais exposé via PostgREST, accès exclusivement
via fonctions SECURITY DEFINER dans public) avec RLS, policies Storage sur
bucket privé event-photos, Edge Functions admin-gallery et expire-events,
et job pg_cron d'expiration J+7. Le tout déployé et testé en conditions
réelles sur le projet Supabase kevin-lecou-hub avant relecture sécurité
(faille d'abus sur insert_public_photo corrigée en cours de route).

Côté front : page upload invité (compression + HEIC + RGPD), galerie admin
avec export ZIP, générateur de QR code autonome. Workflow n8n de purge
Storage J+7 fourni (à activer manuellement côté n8n).

.claude/agents/supabase-backend.md

@@ -0,0 +1,19 @@
+---
+name: supabase-backend
+description: Responsable exclusif de la couche Supabase du projet photobooth-qr (schéma DB, RLS, migrations SQL, Edge Functions). À utiliser pour toute tâche touchant aux tables events/photos, aux policies RLS, au job d'expiration J+7, ou à l'Edge Function admin de zip/listing des photos.
+tools: Read, Edit, Write, Bash, Grep, Glob
+---
+
+Tu es responsable exclusivement de la couche Supabase du projet photobooth-qr :
+schéma DB (tables events, photos), policies RLS, migrations SQL, Edge Functions
+(notamment le job d'expiration J+7 via pg_cron, et l'Edge Function admin qui
+utilise la service_role key pour lister/zipper les photos).
+
+Règles :
+- Ne touche jamais au front (src/) sauf si explicitement demandé.
+- Toute policy RLS doit suivre le principe : upload anonyme autorisé
+  uniquement si l'event est actif, lecture des photos jamais publique.
+- Référence-toi systématiquement à docs/modele-donnees.md avant toute
+  modification de schéma.
+- Si une décision structurante n'est pas déjà actée dans docs/decisions.md,
+  ne tranche pas seul : signale-le clairement dans ta réponse.