feat: migre le site vers SvelteKit (Svelte 5, statique, zéro tiers)

- Rebuild complet SvelteKit 2 + Svelte 5 runes + TypeScript, adapter-static
- Images self-hébergées optimisées au build (vite-imagetools), fonts Archivo/Inter
  en woff2 local — BunnyCDN et Google Fonts supprimés (corrige les 403 d'images)
- Tokens charte OKI, thème sombre par défaut / clair opt-in, zéro emoji (set SVG)
- Motion : KineticText (stagger syncopé gwoka), ScrollProgressBar, View Transitions
- Village SVG isométrique pour les services hébergés + fallback accessible
- PWA (manifest + SW hors-ligne), 404 en KA, CSP nettoyée (.htaccess + _headers)
- Lighthouse mobile : 91/100/100/100 — JS initial 67 Ko gzip

DEPLOY.md

@@ -0,0 +1,45 @@
+# Déploiement — o-k-i.net (SvelteKit statique)
+
+Le site est entièrement pré-rendu : `npm run build` produit un dossier `build/` de fichiers statiques servable par n'importe quel hébergement de fichiers, **sans serveur Node**.
+
+```bash
+npm install
+npm run build   # → build/
+```
+
+Contenu notable de `build/` : pages HTML par route (`index.html`, `dons/index.html`, `en/…`), assets fingerprintés (`_app/`), polices (`fonts/`), PDF presse (`assets/press/`), PWA (`sw.js`, `registerSW.js`, `manifest.webmanifest`), `404.html`, `robots.txt`, `sitemap.xml`.
+
+---
+
+## Option A — o2switch (Apache, mutualisé)
+
+1. Builder en local puis transférer **le contenu de `build/`** à la racine web du domaine (via FTP/SFTP ou le gestionnaire de fichiers cPanel), typiquement `public_html/`.
+2. **Conserver le fichier `build/.htaccess`** (fichier caché — vérifier qu'il est bien transféré). Il contient :
+   - redirection HTTP → HTTPS (compatible proxy),
+   - `ErrorDocument 404 /404.html`,
+   - headers de sécurité (HSTS, CSP `default-src 'self'`, `X-Frame-Options: DENY`, `nosniff`, `Referrer-Policy`, `Permissions-Policy`),
+   - cache immutable pour `/_app/` et `/fonts/`.
+3. HTTPS : activer le certificat Let's Encrypt dans cPanel (la redirection exempte `.well-known/acme-challenge/`).
+4. Vérifications post-déploiement :
+   - `curl -sI https://o-k-i.net/` → headers de sécurité présents,
+   - `curl -s https://o-k-i.net/ | grep -c "b-cdn.net\|googleapis"` → `0`,
+   - une URL inexistante → page 404 designée avec statut 404.
+
+> Le service worker (`sw.js`) est servi en `text/javascript` par défaut sous Apache — rien à configurer.
+
+## Option B — Cloudflare Pages
+
+1. Projet Pages connecté au dépôt, ou déploiement direct : `npx wrangler pages deploy build`.
+2. Configuration du projet :
+   - **Build command** : `npm run build`
+   - **Build output directory** : `build`
+3. **Le fichier `build/_headers` est pris en compte automatiquement** par Cloudflare Pages (headers de sécurité + cache immutable). Ne pas le supprimer.
+4. La page 404 : Cloudflare Pages sert automatiquement `/404.html` avec le statut 404 pour les routes inconnues.
+5. HTTPS/HSTS : gérés par Cloudflare ; le header HSTS est aussi dans `_headers`.
+
+## Points communs
+
+- **Aucune variable d'environnement** n'est nécessaire au build.
+- Le site fonctionne sans JavaScript côté serveur ; les seuls scripts sont statiques (`theme.js`, `lang-redirect.js`, `registerSW.js`, bundles `_app/`).
+- CSP stricte : si vous ajoutez un jour une ressource externe, il faudra l'ajouter à la CSP (dans `.htaccess` ET `_headers`) — ou mieux, la self-héberger.
+- Les PDF de presse (~34 Mo dans `assets/press/`) font partie du déploiement.