docs: améliorer rendu markdown et navigation mkdocs

- Ajouter ADR-018 (librairies Go) dans TECHNICAL.md
- Transformer Shared en menu dépliable dans mkdocs (cohérence avec autres domaines)
- Corriger listes markdown (ajout lignes vides avant listes)
- Corriger line breaks dans génération BDD (étapes "Et" sur nouvelles lignes)
- Ajouter script fix-markdown-lists.sh pour corrections futures

Impacte 86 fichiers de documentation et 164 fichiers BDD générés.

docs/adr/022-strategie-cicd-monorepo.md

@@ -8,6 +8,7 @@
 RoadWave est organisé en monorepo contenant backend Go, mobile Flutter, documentation et features BDD ([ADR-014](014-organisation-monorepo.md)). Sans optimisation, chaque commit déclencherait **tous** les builds (backend + mobile + docs), même si seul un composant a changé.
 
 **Problématique** :
+
 - ❌ Temps de CI/CD inutilement longs (rebuild complet ~15 min)
 - ❌ Gaspillage de ressources GitHub Actions
 - ❌ Ralentissement du feedback développeur
@@ -44,6 +45,7 @@ RoadWave est organisé en monorepo contenant backend Go, mobile Flutter, documen
 #### Workflow Backend (`backend.yml`)
 
 **Déclencheurs** :
+
 - Branches : `main`, `develop`
 - Chemins surveillés :
   - `backend/**` : Code Go, migrations, configuration
@@ -52,6 +54,7 @@ RoadWave est organisé en monorepo contenant backend Go, mobile Flutter, documen
   - `.github/workflows/backend.yml` : Modifications du workflow lui-même
 
 **Jobs exécutés** :
+
 - **Tests unitaires** : Exécution `go test` sur tous les packages
 - **Tests d'intégration** : Utilisation de Testcontainers avec PostgreSQL/PostGIS
 - **Tests BDD** : Exécution Godog sur features `api/` et `e2e/`
@@ -65,6 +68,7 @@ RoadWave est organisé en monorepo contenant backend Go, mobile Flutter, documen
 #### Workflow Mobile (`mobile.yml`)
 
 **Déclencheurs** :
+
 - Branches : `main`, `develop`
 - Chemins surveillés :
   - `mobile/**` : Code Flutter/Dart, assets, configuration
@@ -73,6 +77,7 @@ RoadWave est organisé en monorepo contenant backend Go, mobile Flutter, documen
   - `.github/workflows/mobile.yml` : Modifications du workflow lui-même
 
 **Jobs exécutés** :
+
 - **Tests unitaires** : Exécution `flutter test` sur widgets et logique métier
 - **Tests d'intégration** : Tests d'intégration Flutter (interactions UI complexes)
 - **Lint** : Analyse statique `flutter analyze`
@@ -80,6 +85,7 @@ RoadWave est organisé en monorepo contenant backend Go, mobile Flutter, documen
 - **Build iOS** : Compilation IPA release sans codesign (dépend des tests)
 
 **Environnement** :
+
 - Tests/Lint/Build Android : Ubuntu latest
 - Build iOS : macOS latest (requis pour Xcode)
 - Flutter 3.16.0+
@@ -89,6 +95,7 @@ RoadWave est organisé en monorepo contenant backend Go, mobile Flutter, documen
 #### Workflow Shared (`shared.yml`)
 
 **Déclencheurs** :
+
 - Branches : `main`, `develop`
 - Chemins surveillés :
   - `docs/**` : ADR, règles métier, documentation technique
@@ -96,6 +103,7 @@ RoadWave est organisé en monorepo contenant backend Go, mobile Flutter, documen
   - `.github/workflows/shared.yml` : Modifications du workflow lui-même
 
 **Jobs exécutés** :
+
 - **Validation documentation** : Build MkDocs en mode strict (détecte erreurs markdown)
 - **Vérification liens** : Validation des liens internes/externes dans documentation
 - **Tests code partagé** : Exécution tests si du code partagé backend-mobile existe
@@ -117,6 +125,7 @@ RoadWave est organisé en monorepo contenant backend Go, mobile Flutter, documen
 | **Commit mixte (backend + mobile + docs)** | ✅ | ✅ | ✅ | ~13 min (parallèle) |
 
 **Économie de temps** :
+
 - Commit backend-only : ~5 min (vs 15 min sans path filters) = **67% plus rapide**
 - Commit docs-only : ~30s (vs 15 min) = **97% plus rapide**
 
@@ -125,6 +134,7 @@ RoadWave est organisé en monorepo contenant backend Go, mobile Flutter, documen
 Les tests end-to-end dans `/features/e2e/` **déclenchent les deux workflows** (backend ET mobile) car ils testent l'intégration complète :
 
 **Exemples de features E2E** :
+
 - `features/e2e/abonnements/` : Formulaire mobile → API Zitadel → API RoadWave → Mangopay → Confirmation UI
 - `features/e2e/error-handling/` : Perte réseau → Fallback mode offline → Reprise auto après reconnexion
 
@@ -159,6 +169,7 @@ Les tests end-to-end dans `/features/e2e/` **déclenchent les deux workflows** (
 ❌ **Complexité initiale** : setup plus complexe que workflow monolithique
 
 **Mitigation** :
+
 - Utiliser des **composite actions** pour partager la config commune
 - Documentation claire dans ce ADR
 - Coût initial faible (~2h setup) vs gains à long terme importants
@@ -177,15 +188,18 @@ Les tests end-to-end dans `/features/e2e/` **déclenchent les deux workflows** (
 ### Plan d'Implémentation
 
 **Phase 1** : Setup workflows de base (~1h)
+
 - Créer `backend.yml` avec jobs test + lint + build
 - Créer `mobile.yml` avec jobs test + lint + build
 - Créer `shared.yml` avec validation docs
 
 **Phase 2** : Configuration path filters (~30 min)
+
 - Ajouter `paths:` à chaque workflow
 - Tester avec commits isolés (backend-only, mobile-only, docs-only)
 
 **Phase 3** : Optimisations (~30 min)
+
 - Ajouter caching (Go modules, Flutter dependencies, node_modules)
 - Créer composite actions pour config partagée
 - Ajouter badges status dans README
@@ -226,6 +240,7 @@ Les tests end-to-end dans `/features/e2e/` **déclenchent les deux workflows** (
 ⚠️ **Faux négatifs** : path filter mal configuré → test non exécuté → bug en production
 
 **Mitigation** :
+
 - Features E2E déclenchent toujours backend + mobile (safety net)
 - Tests de validation dans le plan d'implémentation
 - Review obligatoire des modifications de workflows