fix(seed): documenter --default-character-set=utf8mb4 sous Windows

Le client mysql sous Windows + Git Bash utilise cp850 comme
`character_set_client` par défaut. Quand on applique 002_seed_categories.sql
avec un simple `mysql < ...`, le client réinterprète les bytes UTF-8 du fichier
via cp850 AVANT de les insérer : `é` (0xC3 0xA9) devient `├®` (E2949C C2AE)
stocké en clair dans la base, et apparaît tel quel dans l'API + le SPA.

Le `SET NAMES utf8mb4` côté serveur ne corrige pas ça parce que la conversion
est déjà faite côté client. Il faut le flag `--default-character-set=utf8mb4`
sur la ligne de commande mysql.

  - README.md : doc de la commande correcte + commande de vérif HEX
  - 002_seed_categories.sql : commentaire d'alerte + SET NAMES utf8mb4 (no-op
    côté connexion mais documente l'intention)

Côté prod (apply.sh + docker exec mariadb) le client interne utilise utf8mb4
par défaut, donc pas de souci là-bas.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

migrations/002_seed_categories.sql

@@ -1,3 +1,10 @@
+-- Ce fichier contient des caractères accentués (é, É, ...). À appliquer avec
+-- un client MySQL en charset utf8mb4. Sous Windows + Git Bash, passer
+-- `--default-character-set=utf8mb4` à la commande mysql, sinon le client
+-- réinterprète les bytes UTF-8 via cp850 et stocke des `├®` à la place des `é`.
+-- Voir README.md "Appliquer les migrations".
+SET NAMES utf8mb4;
+
 INSERT INTO categories (slug, name, description, color_hex, icon, dimension, sort_order) VALUES
 ('data-open-data',        'Data & Open Data',         'Projets autour de la donnée ouverte, de la médiation et de la littératie des données.',                '#3B82F6', 'database',      'transversal', 10),
 ('democratie-citoyennete','Démocratie & Citoyenneté', 'Projets favorisant la participation citoyenne, la transparence et la gouvernance ouverte.',          '#EF4444', 'users',         'social',      20),