refactor(docs): réorganiser la documentation selon principes DDD

Réorganise la documentation du projet selon les principes du Domain-Driven Design (DDD) pour améliorer la cohésion, la maintenabilité et l'alignement avec l'architecture modulaire du backend.

**Structure cible:**
```
docs/domains/
├── README.md (Context Map)
├── _shared/ (Core Domain)
├── recommendation/ (Supporting Subdomain)
├── content/ (Supporting Subdomain)
├── moderation/ (Supporting Subdomain)
├── advertising/ (Generic Subdomain)
├── premium/ (Generic Subdomain)
└── monetization/ (Generic Subdomain)
```

**Changements effectués:**

Phase 1: Création de l'arborescence des 7 bounded contexts
Phase 2: Déplacement des règles métier (01-19) vers domains/*/rules/
Phase 3: Déplacement des diagrammes d'entités vers domains/*/entities/
Phase 4: Déplacement des diagrammes flux/états/séquences vers domains/*/
Phase 5: Création des README.md pour chaque domaine
Phase 6: Déplacement des features Gherkin vers domains/*/features/
Phase 7: Création du Context Map (domains/README.md)
Phase 8: Mise à jour de mkdocs.yml pour la nouvelle navigation
Phase 9: Correction automatique des liens internes (script fix-markdown-links.sh)
Phase 10: Nettoyage de l'ancienne structure (regles-metier/, diagrammes/, features/)

**Configuration des tests:**
- Makefile: godog run docs/domains/*/features/
- scripts/generate-bdd-docs.py: features_dir → docs/domains

**Avantages:**
✅ Cohésion forte: toute la doc d'un domaine au même endroit
✅ Couplage faible: domaines indépendants, dépendances explicites
✅ Navigabilité améliorée: README par domaine = entrée claire
✅ Alignement code/docs: miroir de backend/internal/
✅ Onboarding facilité: exploration domaine par domaine
✅ Tests BDD intégrés: features au plus près des règles métier

Voir docs/REFACTOR-DDD.md pour le plan complet.

docs/domains/moderation/features/api/detection-patterns-suspects.feature

@@ -0,0 +1,84 @@
+# language: fr
+
+@api @moderation @ml @security @mvp
+Fonctionnalité: Détection de patterns suspects par ML
+
+  En tant que système de sécurité
+  Je veux détecter automatiquement les comportements suspects
+  Afin de prévenir les abus et fraudes
+
+  Scénario: Détection de signalements coordonnés
+    Étant donné 5 utilisateurs qui signalent le même contenu en 10 minutes
+    Et leurs comptes ont été créés la même semaine
+    Quand le système analyse le pattern
+    Alors une alerte "Brigade de signalement" est déclenchée
+    Et les signalements sont mis en quarantaine
+    Et un modérateur vérifie manuellement
+    Et un événement "COORDINATED_REPORTING_DETECTED" est enregistré
+
+  Scénario: Détection de compte bot de signalement
+    Étant donné un compte avec pattern suspect:
+      | Indicateur                  | Valeur      |
+      | Signalements par jour       | 50          |
+      | Intervalle régulier         | Exactement 120s |
+      | Diversité de contenus       | Faible      |
+      | Interaction humaine         | Aucune      |
+    Quand le système ML analyse
+    Alors le compte est identifié comme "Probable bot"
+    Et suspendu automatiquement
+    Et un événement "BOT_ACCOUNT_DETECTED" est enregistré
+
+  Scénario: Détection de vendetta personnelle
+    Étant donné un utilisateur A qui signale systématiquement l'utilisateur B
+    Et 15 signalements en 1 semaine, tous rejetés
+    Quand le système détecte le pattern
+    Alors une alerte "Harcèlement par signalements" est déclenchée
+    Et l'utilisateur A est bloqué de signaler B
+    Et un événement "VENDETTA_PATTERN_DETECTED" est enregistré
+
+  Scénario: Détection d'usage d'IA pour contenu  offensant déguisé
+    Étant donné un contenu avec texte subtil généré par IA
+    Quand l'analyse NLP détecte des marqueurs d'IA toxique
+    Alors le contenu est mis en quarantaine
+    Et un modérateur expert vérifie
+    Et un événement "AI_GENERATED_TOXIC_DETECTED" est enregistré
+
+  Scénario: Analyse des métadonnées EXIF suspectes
+    Étant donné une image uploadée avec métadonnées:
+      | Métadonnée          | Valeur suspect       |
+      | GPS Location        | Corée du Nord        |
+      | Device Model        | Connu pour bots      |
+      | Timestamp           | Futur (2027)         |
+    Quand le système analyse
+    Alors l'image est marquée "Métadonnées suspectes"
+    Et un événement "SUSPICIOUS_METADATA_DETECTED" est enregistré
+
+  Scénario: Score de risque ML combiné
+    Étant donné un contenu analysé par ML
+    Alors un score de risque global est calculé:
+      | Facteur                   | Poids | Score |
+      | Contenu textuel           | 30%   | 0.8   |
+      | Métadonnées image         | 20%   | 0.3   |
+      | Comportement utilisateur  | 30%   | 0.9   |
+      | Patterns de signalement   | 20%   | 0.1   |
+      | **Score global**          | 100%  | **0.65** |
+    Et si score > 0.7, mise en quarantaine automatique
+    Et un événement "ML_RISK_SCORE_CALCULATED" est enregistré
+
+  Scénario: Apprentissage continu du modèle ML
+    Étant donné 10 000 contenus modérés manuellement
+    Quand les décisions humaines sont collectées
+    Alors le modèle ML est réentraîné mensuellement
+    Et la précision s'améliore de 2-3% par itération
+    Et un événement "ML_MODEL_RETRAINED" est enregistré
+
+  Scénario: Métriques de performance de la détection ML
+    Étant donné que 50 000 contenus ont été analysés
+    Alors les indicateurs suivants sont disponibles:
+      | Métrique                      | Valeur |
+      | Précision de détection        | 87%    |
+      | Rappel (contenus détectés)    | 82%    |
+      | Faux positifs                 | 8%     |
+      | Temps moyen d'analyse         | 250ms  |
+      | Économie de temps modérateurs | 60%    |
+    Et les métriques sont exportées vers le monitoring