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/api/authentication/sessions-tokens.feature

@@ -0,0 +1,114 @@
+# language: fr
+Fonctionnalité: Gestion des sessions et tokens
+  En tant qu'utilisateur connecté
+  Je veux que mes sessions soient sécurisées et gérées automatiquement
+  Afin de maintenir l'accès à l'application sans friction
+
+  Contexte:
+    Étant donné que l'API RoadWave est disponible
+    Et que je suis connecté avec succès
+
+  Scénario: Access token expire après 15 minutes
+    Étant donné que j'ai reçu un access token
+    Et que 15 minutes se sont écoulées
+    Quand je fais une requête API avec cet access token
+    Alors la requête échoue avec le code 401
+    Et je vois le message "Token expiré"
+
+  Scénario: Refresh automatique du token avec refresh token
+    Étant donné que mon access token a expiré
+    Et que mon refresh token est valide
+    Quand l'application demande un nouveau access token
+    Alors je reçois un nouvel access token valide pour 15 minutes
+    Et je reçois un nouveau refresh token (rotation)
+    Et l'ancien refresh token est invalidé
+
+  Scénario: Refresh token expire après 30 jours d'inactivité
+    Étant donné que je me suis connecté il y a 30 jours
+    Et que je n'ai pas utilisé l'application depuis
+    Quand j'essaie d'utiliser mon refresh token
+    Alors la requête échoue
+    Et je dois me reconnecter avec email/password
+
+  Scénario: Prolongation automatique de la session si l'app est utilisée
+    Étant donné que je me suis connecté il y a 25 jours
+    Et que j'utilise l'application régulièrement
+    Quand je fais une requête API
+    Alors ma session est automatiquement prolongée
+    Et mon refresh token reste valide
+
+  Scénario: Détection de token replay attack
+    Étant donné que j'ai rafraîchi mon token
+    Et que j'ai reçu un nouveau refresh token
+    Quand j'essaie de réutiliser l'ancien refresh token
+    Alors la requête échoue
+    Et je vois le message "Token invalide ou révoqué"
+    Et toutes mes sessions sont révoquées par sécurité
+
+  Scénario: Voir la liste des appareils connectés
+    Étant donné que je suis connecté sur 3 appareils différents
+    Quand je consulte la liste de mes appareils connectés
+    Alors je vois 3 appareils avec les informations suivantes:
+      | information        | exemple                    |
+      | OS                 | iOS 17.1                   |
+      | Navigateur         | Safari                     |
+      | Dernière connexion | Il y a 2 heures            |
+      | Localisation       | Paris, France (IP visible) |
+
+  Scénario: Révoquer un appareil spécifique
+    Étant donné que je suis connecté sur mon iPhone et mon iPad
+    Quand je révoque la session de mon iPad depuis les paramètres
+    Alors la session iPad est immédiatement déconnectée
+    Et ma session iPhone reste active
+
+  Scénario: Déconnecter tous les appareils sauf celui en cours
+    Étant donné que je suis connecté sur 4 appareils
+    Quand je clique sur "Déconnecter tous les appareils"
+    Alors les 3 autres appareils sont déconnectés
+    Et seul l'appareil actuel reste connecté
+
+  Scénario: Alerte de connexion depuis nouveau device
+    Étant donné que je me suis toujours connecté depuis Paris
+    Quand je me connecte depuis un nouvel appareil à Lyon
+    Alors je reçois une notification push sur mes autres appareils
+    Et je reçois un email avec:
+      | sujet          | Nouvelle connexion détectée      |
+      | localisation   | Lyon, France                     |
+      | appareil       | Android 14 - Chrome              |
+      | action         | Lien pour révoquer la session    |
+
+  Scénario: Alerte de connexion suspecte depuis pays différent
+    Étant donné que je me suis toujours connecté depuis la France
+    Quand je me connecte depuis un appareil aux États-Unis
+    Alors je reçois une notification push immédiate
+    Et je reçois un email d'alerte de sécurité
+    Et la nouvelle session nécessite une validation 2FA même si désactivée
+
+  Scénario: Déconnexion après 30 jours d'inactivité totale
+    Étant donné que je ne me suis pas connecté depuis 30 jours
+    Quand j'ouvre l'application
+    Alors je suis automatiquement déconnecté
+    Et je dois me reconnecter avec email/password
+    Et je vois le message "Session expirée après 30 jours d'inactivité"
+
+  Scénario: Sessions multiples simultanées autorisées
+    Étant donné que je suis connecté sur:
+      | appareil          |
+      | iPhone            |
+      | iPad              |
+      | PC Windows (Web)  |
+    Quand je fais des actions sur les 3 appareils simultanément
+    Alors toutes les sessions fonctionnent sans conflit
+    Et chaque appareil maintient sa propre session
+
+  Scénario: Validation de JWT via Zitadel
+    Étant donné que j'ai reçu un access token JWT
+    Quand l'API RoadWave valide le token
+    Alors la validation est faite localement avec la clé publique Zitadel
+    Et aucune requête externe n'est effectuée (performance)
+    Et le token contient les claims suivants:
+      | claim | valeur_exemple         |
+      | sub   | user-id-123            |
+      | email | user@test.fr           |
+      | exp   | timestamp + 15 minutes |
+      | iss   | zitadel.roadwave.com   |