feat(gherkin): ajouter features interactions et navigation

Couverture complète des règles métier 05-interactions-navigation.md :

API (Backend) :
- File d'attente : pré-calcul 5 contenus, recalcul auto (>10km, 10min, <3 contenus), invalidation, Redis cache
- Notifications géolocalisées : calcul ETA, déclenchement 7s avant, quota 6/h, cooldown 10min, tracking GPS
- Jauges d'intérêt : architecture services séparés (Calculation + Update), pattern addition points absolus, persistance Redis/PostgreSQL

UI (Frontend) :
- Mode piéton : notifications push arrière-plan, rayon 200m, permissions stratégie progressive, geofencing iOS/Android
- Basculement automatique voiture↔piéton : détection vitesse GPS, hysteresis 10s, transition transparente

Fichiers créés :
- features/api/navigation/file-attente.feature
- features/api/navigation/notifications-geolocalisees.feature
- features/ui/navigation/mode-pieton-notifications-push.feature

Fichiers enrichis :
- features/api/interest-gauges/evolution-jauges.feature (ajout scénarios architecture backend)

features/api/interest-gauges/evolution-jauges.feature

@@ -479,3 +479,89 @@ Fonctionnalité: API - Évolution des jauges d'intérêt
         ]
       }
       """
+
+  # Architecture backend - Services séparés
+
+  Scénario: Gauge Calculation Service calcule l'ajustement (stateless)
+    Étant donné un événement d'écoute avec 85% de complétion
+    Quand le Gauge Calculation Service calcule l'ajustement
+    Alors le service retourne:
+      """json
+      {
+        "adjustment_type": "automatic_reinforced",
+        "adjustment_value": 2.0,
+        "reason": "completion_percentage >= 80%"
+      }
+      """
+    Et le service est stateless (aucune lecture DB)
+    Et le service est testable unitairement
+
+  Scénario: Gauge Update Service applique l'ajustement (stateful)
+    Étant donné qu'un ajustement de +2% a été calculé
+    Et que la jauge "Automobile" de "user123" est à 45%
+    Quand le Gauge Update Service applique l'ajustement
+    Alors la nouvelle valeur est 47% (45 + 2)
+    Et la borne [0, 100] est respectée via fonction clamp
+    Et la mise à jour est persistée en Redis (immédiat)
+    Et la mise à jour est persistée en PostgreSQL (batch async)
+
+  Scénario: Pattern de calcul - Addition de points absolus
+    Étant donné qu'une jauge est à 60%
+    Et qu'un ajustement de +2% est calculé
+    Quand le calcul est effectué
+    Alors la formule est: newValue = currentValue + adjustment
+    Et la formule est: newValue = clamp(newValue, 0.0, 100.0)
+    Et la nouvelle valeur est 62%
+
+  Scénario: Pattern de calcul - Éviter multiplication relative
+    Étant donné qu'une jauge est à 50%
+    Et qu'un ajustement de +2% est calculé
+    Quand le calcul est effectué
+    Alors la formule utilisée est: 50 + 2 = 52
+    Et la formule utilisée n'est PAS: 50 * (1 + 2/100) = 51
+    Car l'ajustement est en points absolus, pas relatifs
+
+  Scénario: Multi-tags - Mise à jour de N jauges simultanément
+    Étant donné qu'un contenu a 3 tags: ["Automobile", "Voyage", "Technologie"]
+    Et qu'un ajustement de +2% est calculé (écoute 85%)
+    Quand le Gauge Update Service applique
+    Alors 3 jauges sont mises à jour:
+      | catégorie    | ajustement |
+      | Automobile   | +2%        |
+      | Voyage       | +2%        |
+      | Technologie  | +2%        |
+    Et toutes les mises à jour sont effectuées en une seule transaction
+
+  Scénario: Persistance Redis immédiate (latence <10ms)
+    Étant donné qu'un ajustement doit être persisté
+    Quand le Gauge Update Service écrit en Redis
+    Alors la latence est < 10ms
+    Et la jauge est immédiatement disponible pour recommandations
+    Et Redis sert de cache haute performance
+
+  Scénario: Persistance PostgreSQL asynchrone (batch 5 min)
+    Étant donné que 100 ajustements ont été appliqués en Redis
+    Quand le batch async s'exécute toutes les 5 minutes
+    Alors les 100 ajustements sont écrits en PostgreSQL en batch
+    Et la cohérence finale est garantie
+    Et l'application reste performante (pas de write sync)
+
+  Scénario: Séparation responsabilités - Calculation vs Update
+    Étant donné un événement d'écoute
+    Quand il est traité
+    Alors le Gauge Calculation Service calcule l'ajustement (logique métier pure)
+    Et le Gauge Update Service applique l'ajustement (persistance)
+    Et les deux services sont indépendants
+    Et chaque service a une responsabilité unique (SRP)
+
+  Scénario: Réutilisabilité Calculation Service
+    Étant donné le Gauge Calculation Service
+    Quand il est utilisé pour:
+      | contexte            |
+      | Like automatique    |
+      | Skip rapide         |
+      | Like manuel         |
+      | Abonnement créateur |
+    Alors le même service calcule tous les ajustements
+    Et la logique métier est centralisée
+    Et il n'y a pas de duplication de code