Retirer les coordonnées des étapes d'un parcours Premium de la recherche #161

Contexte

Epic : #8
Prérequis : #25 (recherche, PR #138)
Maquette : E-04 · validée le 2026-09-23 (D-014), révisée le 2026-09-28 (D-071) · tap Premium sans abonnement
API › Conventions · API › Découverte · API › Card de recherche · Compte-et-Monetisation › Freemium · E-04 · D-014 · D-075

Découverte de CODE pendant #26 (Inbox) : GET /v1/routes/search renvoie, dans steps[] de chaque card, la catégorie et les coordonnées de toutes les étapes, y compris pour un parcours access = premium. L'app les masque (D-014 : ni tracé ni étapes, départ seul), mais elles transitent en clair vers un client non abonné. Or le wiki est explicite : sans abonnement, les étapes 2 et suivantes n'ont « ni nom, ni lieu, ni coordonnées, ni conseil, ni tracé, dans la fiche comme sur la carte (départ seul). Le filtrage se fait dans l'API, pas seulement dans l'app ». C'est un défaut de contrôle d'accès (OWASP A01) sur un endpoint public.

Règle révisée le 2026-09-29 par D-075 : le filtrage ne doit pas dégrader l'abonné. E-04 (D-014, validée par Ilan le 2026-09-23) : « Abonné, le tap validé ne change pas. » Un abonné garde sur la carte l'expérience d'un parcours gratuit ; la voie abonné se livre dans ce ticket.

Comportement attendu

• GET /v1/routes/search reste publique, avec authentification facultative (API › Conventions) : un jeton Firebase est accepté sans être exigé.
• Card verrouillée (isLocked = true), pour un parcours access = premium appelé sans jeton ou par un compte qui n'a pas droit au parcours : steps ne porte que le départ (catégorie et coordonnées, name et durationMin à null) ; les étapes 2 et suivantes ne quittent pas l'API, ni nom, ni lieu, ni coordonnées, ni catégorie, ni photo. stepCount donne le nombre exact d'étapes (tooltip « Parcours Premium · N étapes en X h »).
• Card déverrouillée (isLocked = false), avec le jeton valide d'un compte qui a droit au parcours : toutes les étapes, comme un parcours gratuit.
• Droit au parcours : aujourd'hui users.plan = premium et users.plan_expires_at non passé ; plan expiré = pas de droit. Règle calculée en un seul endroit du code, que Appliquer les parcours Premium, le déblocage à l'unité et la limite anti-spam dans l'API #66 étend (pass 7 jours, déblocage à l'unité) et que Exposer GET /routes/:id et /routes/:id/timeline, stocker computed #36 réutilise pour GET /routes/:id.
• Cache : sans en-tête Authorization, Cache-Control: public (30 s, ETag), comme aujourd'hui ; avec un en-tête Authorization, Cache-Control: private et Vary: Authorization, jamais servie à un autre appelant.
• Jeton présent mais invalide ou expiré : 401 unauthorized, sans repli silencieux sur la réponse anonyme.
• Parcours access = free : isLocked = false, toutes les étapes, stepCount = longueur de steps ; aucun autre changement.
• GET /v1/routes/search/count ne change pas : le comptage ne dépend pas de l'appelant.
• Schéma partagé RouteCard (packages/shared) : isLocked et stepCount ; l'app lit isLocked, jamais access seul, pour choisir l'affichage.
• Carte (E-04) : card verrouillée → recadrage sans tracé ni étapes, départ en pastille encre à couronne, tooltip « Parcours Premium · N étapes en X h » ; card Premium déverrouillée → affichée comme un parcours gratuit (tracé, étapes, tooltips), avec sa pastille Premium.
• packages/api-client : la fonction de recherche accepte un jeton facultatif et l'envoie en Authorization: Bearer quand il est fourni.

Critères d'acceptation

• Test d'intégration : parcours premium sans jeton → card isLocked: true, départ seul (name et durationMin à null), stepCount exact ; aucune coordonnée, aucun nom ni aucune catégorie des étapes 2+ dans le JSON brut de la réponse
• Test d'intégration : même résultat verrouillé avec le jeton d'un compte gratuit (recherche des valeurs dans le JSON brut)
• Test d'intégration : jeton d'un compte premium dont plan_expires_at n'est pas passé → card isLocked: false avec toutes les étapes
• Test d'intégration : jeton d'un compte premium dont plan_expires_at est passé → card verrouillée
• Test d'intégration : jeton invalide ou expiré → 401 unauthorized
• Tests des en-têtes : sans jeton Cache-Control: public avec ETag ; avec jeton Cache-Control: private et Vary: Authorization
• Parcours free inchangé, isLocked: false ; /routes/search/count inchangé
• isLocked dans RouteCard (packages/shared), lu par l'app pour choisir l'affichage (aucune décision d'affichage sur access seul)
• Règle de droit au parcours en un seul endroit du code (fonction unique, testée), appelée par la recherche
• Carte : parcours Premium verrouillé conforme à la maquette tap Premium sans abonnement ; parcours Premium déverrouillé affiché comme un parcours gratuit, avec sa pastille Premium (test de la couche carte sur les deux cas)
• packages/api-client accepte un jeton facultatif pour la recherche
• PR de niveau 2, revue OWASP A01 (et A07 pour la vérification du jeton) dans la section Risque

Notes techniques

• Hors de ce ticket : l'app n'a pas encore de session (connexion : Implémenter la connexion (E-10), le profil (E-09) et la suppression de compte #38, v0.3). L'envoi du jeton par l'app, le rafraîchissement et le nouvel essai sur 401, et le vidage du cache des résultats quand le droit change (connexion, déconnexion) se branchent avec Implémenter la connexion (E-10), le profil (E-09) et la suppression de compte #38 ; la relance de la recherche après un achat ou une restauration avec Brancher RevenueCat et construire l'écran Premium (E-17) #67. Ici, l'app continue d'appeler la recherche sans jeton ; seul le client accepte un jeton facultatif.
• Personne n'est Premium avant Brancher RevenueCat et construire l'écran Premium (E-17) #67 (v0.4) : la voie abonné se prouve par les tests d'intégration.
• steps[].photoUrl (Ajouter la photo du lieu aux étapes de la card de recherche (steps[].photoUrl) #219) suivra les étapes : absente des étapes que la card ne porte pas.