feat(bdd): réorganiser features en catégories api/ui/e2e et créer ADR-024

Résolution des incohérences #10, #11, et #12 de l'analyse d'architecture.

## Phase 1 : Réorganisation Features BDD (Point #10 - RÉSOLU)

- Créer structure features/{api,ui,e2e}
- Déplacer 83 features en 3 catégories via git mv (historique préservé)
  - features/api/ : 53 features (tests API backend)
  - features/ui/ : 22 features (tests UI mobile)
  - features/e2e/ : 8 features (tests end-to-end)

Domaines déplacés :
- API : authentication, recommendation, rgpd-compliance, content-creation,
  moderation, monetisation, premium, radio-live, publicites
- UI : audio-guides, navigation, interest-gauges, mode-offline,
  partage, profil, recherche
- E2E : abonnements, error-handling

## Phase 2 : Mise à jour Documentation

### ADR-007 - Tests BDD
- Ajouter section "Convention de Catégorisation des Features"
- Documenter règles api/ui/e2e avec exemples concrets
- Spécifier step definitions (backend Go, mobile Dart)

### ADR-024 - Stratégie CI/CD Monorepo (NOUVEAU)
- Créer ADR dédié pour stratégie CI/CD avec path filters
- Architecture workflows séparés (backend.yml, mobile.yml, shared.yml)
- Configuration path filters détaillée avec exemples YAML
- Matrice de déclenchement et optimisations (~70% gain temps CI)
- Plan d'implémentation (~2h, reporté jusqu'au développement)

### ADR-016 - Organisation Monorepo
- Simplifier en retirant section CI/CD détaillée
- Ajouter référence vers ADR-024 pour stratégie CI/CD

### INCONSISTENCIES-ANALYSIS.md
- Point #10 (Tests BDD synchronisés) : ✅ RÉSOLU
  - Catégorisation features implémentée
  - ADR-007 mis à jour avec convention complète
- Point #11 (70/30 Split paiements) : ✅ ANNULÉ (faux problème)
  - ADR-009 et Règle 18 parfaitement cohérents
  - Documentation exhaustive existante (formule, SQL, comparaisons)
- Point #12 (Monorepo path filters) : ⏸️ DOCUMENTÉ
  - Architecture CI/CD complète dans ADR-024
  - Implémentation reportée (projet en phase documentation)
- Métriques mises à jour :
  - MODERATE : 6/9 traités (4 résolus + 1 annulé + 1 documenté)
  - ADR à jour : 100% (19/19 avec ADR-024)

## Phase 3 : Validation

- Structure features validée (api/ui/e2e, aucun répertoire restant)
- Historique Git préservé (git mv, renommages détectés)
- 83 features total (API: 53, UI: 22, E2E: 8)

Closes: Point #10 (résolu), Point #11 (annulé), Point #12 (documenté)

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

features/e2e/error-handling/perte-reseau.feature

@@ -0,0 +1,179 @@
+# language: fr
+
+@error-handling @network-loss
+Fonctionnalité: Gestion de la perte de réseau et buffering adaptatif
+
+  Contexte:
+    Étant donné que je suis un utilisateur connecté
+    Et que je suis en mode écoute
+    Et qu'un contenu est en cours de lecture
+
+  # 12.3 - Buffer adaptatif selon type de réseau (cf. TECHNICAL.md et ADR-002)
+
+  Plan du Scénario: Paramètres de buffer selon le type de réseau
+    Étant donné que je suis connecté en "<type_reseau>"
+    Quand le système initialise le buffer audio
+    Alors le buffer minimum est de <buffer_min> secondes
+    Et le buffer cible est de <buffer_cible> secondes
+    Et le buffer maximum est de <buffer_max> secondes
+
+    Exemples:
+      | type_reseau | buffer_min | buffer_cible | buffer_max |
+      | WiFi        | 5          | 30           | 120        |
+      | 4G          | 10         | 45           | 120        |
+      | 5G          | 10         | 45           | 120        |
+      | 3G          | 30         | 90           | 300        |
+
+  # Phase 1: Connexion instable
+
+  Scénario: Connexion instable avec latence élevée - aucun message immédiat
+    Étant donné que je suis connecté en 4G
+    Et que le buffer contient 45 secondes de contenu
+    Quand la latence réseau dépasse 500ms
+    Alors aucun message n'est affiché immédiatement
+    Et la lecture continue normalement sur le buffer
+    Et le système tente de continuer le téléchargement en arrière-plan
+
+  Scénario: Connexion instable pendant plus de 10 secondes - toast discret
+    Étant donné que je suis connecté en 4G
+    Et que la latence réseau dépasse 500ms depuis 10 secondes
+    Quand le système détecte la latence prolongée
+    Alors un toast discret s'affiche: "Connexion instable"
+    Et le toast disparaît automatiquement après 3 secondes
+    Et la lecture continue normalement
+
+  # Phase 2: Perte totale réseau
+
+  Scénario: Perte totale de réseau - lecture sur buffer
+    Étant donné que je suis connecté en WiFi
+    Et que le buffer contient 30 secondes de contenu
+    Quand je perds totalement la connexion réseau
+    Alors la lecture continue sur le buffer disponible
+    Et un toast s'affiche: "Hors ligne, lecture sur buffer (30s restantes)"
+    Et un compte à rebours du temps de buffer restant est visible
+
+  Scénario: Buffer qui s'épuise pendant la perte réseau
+    Étant donné que je suis hors ligne
+    Et que le buffer contient 30 secondes de contenu
+    Quand le contenu continue de jouer
+    Alors le compte à rebours diminue en temps réel
+    Et le toast affiche "Hors ligne, lecture sur buffer (15s restantes)" après 15 secondes
+    Et le toast affiche "Hors ligne, lecture sur buffer (5s restantes)" après 25 secondes
+
+  # Phase 3: Buffer épuisé sans reconnexion
+
+  Scénario: Pause automatique après épuisement du buffer
+    Étant donné que je suis hors ligne depuis 30 secondes
+    Et que le buffer est complètement épuisé
+    Quand il n'y a plus de contenu audio à lire
+    Alors la lecture se met en pause automatiquement
+    Et un overlay s'affiche: "Connexion perdue. Reconnexion en cours..."
+    Et le système tente de se reconnecter automatiquement
+
+  Scénario: Tentatives de reconnexion automatique
+    Étant donné que la lecture est en pause suite à l'épuisement du buffer
+    Quand le système tente de se reconnecter
+    Alors une tentative de reconnexion est effectuée toutes les 5 secondes
+    Et un maximum de 6 tentatives sont effectuées (30 secondes au total)
+    Et l'overlay affiche "Tentative de reconnexion... (X/6)"
+
+  # Phase 4: Basculement mode offline après échec reconnexion
+
+  Scénario: Proposition du mode offline après 30 secondes d'échec
+    Étant donné que 6 tentatives de reconnexion ont échoué
+    Et que cela fait 30 secondes que je suis déconnecté
+    Quand la 6ème tentative échoue
+    Alors une popup s'affiche: "Voulez-vous continuer avec vos contenus téléchargés ?"
+    Et la popup contient deux boutons:
+      | bouton        | action                              |
+      | Réessayer     | Nouvelle série de 6 tentatives      |
+      | Mode offline  | Bascule sur contenus téléchargés    |
+
+  Scénario: Basculement réussi vers le mode offline
+    Étant donné que la popup de mode offline est affichée
+    Et que j'ai téléchargé 20 contenus dans ma zone géographique
+    Quand je clique sur "Mode offline"
+    Alors le système bascule sur les contenus téléchargés
+    Et un nouveau contenu téléchargé démarre automatiquement
+    Et un bandeau permanent indique "Mode hors ligne - Contenus téléchargés"
+
+  Scénario: Aucun contenu téléchargé disponible
+    Étant donné que la popup de mode offline est affichée
+    Et que je n'ai aucun contenu téléchargé
+    Quand je clique sur "Mode offline"
+    Alors un message s'affiche: "Aucun contenu téléchargé disponible"
+    Et je suis invité à me connecter en WiFi pour télécharger du contenu
+    Et le bouton "Réessayer" reste la seule option
+
+  # Reconnexion réussie
+
+  Scénario: Reprise automatique après reconnexion
+    Étant donné que la lecture est en pause depuis 15 secondes
+    Et que j'étais à 02:35 du contenu en cours
+    Quand la connexion réseau est rétablie
+    Alors la lecture reprend automatiquement au point d'arrêt exact (02:35)
+    Et un toast s'affiche: "Connexion rétablie"
+    Et le toast disparaît après 3 secondes
+    Et le buffer se remplit progressivement selon le type de réseau
+
+  Scénario: Reconnexion avec changement de type de réseau
+    Étant donné que j'étais connecté en WiFi
+    Et que j'ai perdu la connexion
+    Quand je me reconnecte en 4G
+    Alors le système ajuste automatiquement les paramètres de buffer
+    Et le buffer minimum passe de 5s à 10s
+    Et le buffer cible passe de 30s à 45s
+    Et la lecture reprend normalement
+
+  # Cas spécifique: tunnel routier
+
+  Scénario: Passage dans un tunnel avec perte de signal
+    Étant donné que je conduis à 90 km/h sur autoroute
+    Et que je suis connecté en 4G avec un buffer de 45 secondes
+    Quand j'entre dans un tunnel et perds le signal
+    Alors la lecture continue sur le buffer pendant 45 secondes maximum
+    Et aucune notification n'est affichée pendant les 10 premières secondes
+    Et un toast discret s'affiche après 10 secondes: "Connexion instable"
+
+  Scénario: Sortie du tunnel avant épuisement du buffer
+    Étant donné que je suis dans un tunnel depuis 30 secondes
+    Et qu'il reste 15 secondes de buffer
+    Quand je sors du tunnel et récupère le signal 4G
+    Alors la lecture continue sans interruption
+    Et le buffer se remplit à nouveau
+    Et un toast s'affiche: "Connexion rétablie"
+
+  # Handoff réseau (changement de cellule mobile)
+
+  Scénario: Changement de cellule 4G pendant la lecture
+    Étant donné que je conduis et change de cellule mobile toutes les 5-10 minutes
+    Et que le buffer contient 45 secondes de contenu
+    Quand un handoff de cellule se produit
+    Alors la lecture continue sans interruption grâce au buffer
+    Et la connexion à la nouvelle cellule se fait de manière transparente
+    Et aucune notification n'est affichée si le handoff réussit en moins de 5 secondes
+
+  # Mode offline préventif avant perte réseau
+
+  Scénario: Téléchargement préventif en WiFi avant trajet
+    Étant donné que je suis connecté en WiFi
+    Et que j'ai activé le téléchargement automatique
+    Quand le système détecte que je suis à l'arrêt en WiFi
+    Alors le système me propose de télécharger du contenu pour mon trajet
+    Et je peux sélectionner une zone géographique à télécharger
+    Et le téléchargement se fait en arrière-plan
+
+  # Métriques et monitoring
+
+  Scénario: Tracking des événements de perte réseau pour amélioration
+    Étant donné que je perds la connexion réseau
+    Quand l'événement de perte est détecté
+    Alors le système enregistre les métriques suivantes:
+      | métrique                    |
+      | Type de réseau avant perte  |
+      | Durée de la coupure         |
+      | Buffer disponible           |
+      | Position GPS approximative  |
+      | Heure de la journée         |
+    Et ces métriques sont anonymisées et envoyées en batch lors de la prochaine connexion WiFi
+    Et les données servent à améliorer les paramètres de buffer