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).

supabase/migrations/20260916090000_create_photobooth_schema.sql

@@ -0,0 +1,38 @@
+-- Migration : schéma dédié `photobooth`
+--
+-- Changement d'architecture (décision actée avec Kévin, 2026-09-16) :
+-- le projet Supabase définitif ("kevin-lecou-hub", ref ctveboqnbatwmadwsnvw)
+-- est mutualisé avec de futurs produits. Plutôt qu'un préfixe `pq_` sur des
+-- tables dans `public` (approche de la veille), on isole désormais
+-- photobooth-qr dans son propre schéma Postgres `photobooth`. Les tables
+-- s'appellent donc simplement `events` / `photos` (sans préfixe), l'isolation
+-- venant du schéma et non plus du nom de table.
+--
+-- Contrainte technique actée : exposer un schéma custom via l'API REST
+-- (PostgREST) nécessite un réglage MANUEL dans le dashboard Supabase
+-- ("Exposed schemas", Project Settings > Data API) — impossible à faire en
+-- SQL pur. Décision : ne JAMAIS faire ce réglage pour `photobooth`. Ce
+-- schéma reste **totalement privé, jamais exposé via PostgREST** — ni pour
+-- `anon`, ni pour `service_role` (l'exposition de schéma chez PostgREST est
+-- un filtre au niveau du routage HTTP, indépendant du rôle appelant : même
+-- avec la service_role key, un accès REST direct à `photobooth.events`
+-- n'aurait aucune route pour y répondre).
+--
+-- Tout accès (anon ET service_role) passe donc exclusivement par des
+-- fonctions SECURITY DEFINER dans le schéma `public` (qui, lui, reste
+-- exposé par défaut) — cf. 20260916090400_create_public_functions.sql.
+--
+-- ⚠️ Ne pas appliquer depuis cet agent : Kévin applique lui-même via son
+-- accès MCP Supabase direct une fois la relecture faite.
+
+create schema if not exists photobooth;
+
+comment on schema photobooth is
+  'Schéma dédié au projet photobooth-qr (mariage/soirée, galerie photo par QR code). JAMAIS ajouté aux "Exposed schemas" (Project Settings > Data API) : aucun accès direct via PostgREST, ni anon ni service_role. Tout accès passe par des fonctions SECURITY DEFINER dans public.';
+
+-- Défensif / documentaire plutôt que strictement nécessaire : un schéma
+-- nouvellement créé n'accorde par défaut AUCUN privilège à PUBLIC (ce
+-- comportement spécial n'existe que pour le schéma `public` historique).
+-- On le rend explicite pour que l'intention soit lisible sans dépendre de
+-- ce détail de comportement Postgres.
+revoke all on schema photobooth from public;