refactor(docs): réorganiser ADR et règles métier pour clarté

**Changements majeurs** :

1. **Suppression ADR-010 (Commandes volant et likes)** :
   - Contenu consolidé dans Règle 05 (section 5.3)
   - Raison : ADR-010 était du métier déguisé en architecture
   - Section "Implémentation Technique" ajoutée à Règle 05
   - Pattern correct (addition) vs incorrect (multiplication)

2. **Déplacement ADR-011 → Compliance** :
   - `docs/adr/011-conformite-stores.md` → `docs/compliance/stores-submission.md`
   - Raison : Nature opérationnelle/légale, pas architecture technique
   - Nouveau dossier `/docs/compliance/` créé

3. **Renumérotation ADR (010-022)** :
   - Combler les trous de numérotation (010 et 011)
   - ADR-012→010, ADR-013→011, ..., ADR-024→022
   - 22 ADR numérotés en continu (001-022)
   - Historique Git préservé (git mv)

4. **Mise à jour références** :
   - Règle 03 : ADR-010 → Règle 05 (section 5.3)
   - Règle 09 : ADR-010 → Règle 05 (section 5.3)
   - INCONSISTENCIES-ANALYSIS.md : toutes références mises à jour
   - Incohérence #15 annulée (faux problème : modes séparés)

**Résultat** :
- ✅ Séparation claire ADR (technique) vs Règles métier (fonctionnel)
- ✅ Documentation compliance séparée
- ✅ Numérotation ADR continue sans trous
- ✅ Single Source of Truth (pas de redondance)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

docs/adr/010-architecture-backend.md

@@ -0,0 +1,50 @@
+# ADR-010 : Architecture Backend
+
+**Statut** : Accepté
+**Date** : 2025-01-20
+
+## Contexte
+
+RoadWave nécessite une architecture backend évolutive tout en gardant la simplicité opérationnelle pour un MVP. Le système doit supporter une croissance progressive de 0 à 10M utilisateurs.
+
+## Décision
+
+**Monolithe modulaire** avec séparation claire en modules internes.
+
+## Alternatives considérées
+
+| Architecture | Complexité | Coûts infra | Time to market | Évolutivité |
+|--------------|------------|-------------|----------------|-------------|
+| **Monolithe modulaire** | Faible | Faible | Rapide | 0-1M users |
+| Microservices | Élevée | Élevée | Lent | 1M+ users |
+| Hybrid (Mono + Workers) | Moyenne | Moyenne | Moyen | 100K-5M users |
+
+## Justification
+
+- **Simplicité** : 1 seul binaire Go, déploiement trivial
+- **Transactions** : Communications inter-modules en mémoire (pas de latence réseau)
+- **Debugging** : Stack traces complètes, profiling unifié
+- **Coûts** : 1 serveur suffit pour 100K users (vs N services)
+- **Refactoring** : Modules internes bien séparés facilitent migration vers microservices si nécessaire
+
+## Structure modulaire
+
+```
+internal/
+├── auth/         # Validation JWT, intégration Zitadel
+├── user/         # Profils, centres d'intérêt
+├── content/      # CRUD contenus, métadonnées
+├── geo/          # Recherche géospatiale, algorithme
+├── streaming/    # Génération HLS, transcoding
+├── moderation/   # Signalements, workflow
+├── payment/      # Intégration Mangopay
+└── analytics/    # Métriques écoute, jauges
+```
+
+Chaque module suit : `handler.go` → `service.go` → `repository.go`.
+
+## Conséquences
+
+- Scaling horizontal : réplication complète du binaire (acceptable jusqu'à 1M users)
+- Transition vers microservices possible en phase 2 (extraction progressive des modules)
+- Importance de maintenir découplage fort entre modules (interfaces claires)