fix(api): ouvrir « Itinéraire » dans le mode du trajet vers l'étape

[PaulThiberville]

Résultat et problème

« Itinéraire » ouvrait toujours Google Maps à pied : GET /v1/me/planned/:id/maps-url écrivait travelmode=walking (walkingMapsUrl de l'API), et l'app recopiait la même URL à pied hors connexion. Le report de l'éditeur sur E-07 (D-052) demande le mode du trajet.

• packages/orchestration/src/maps.ts : travelModeOf (walk → walking, bike → bicycling, metro → transit, car → driving) et stepMapsUrl(steps, index), qui ouvre l'étape dans le mode du trajet qui y mène (transition.mode de l'étape précédente), à pied pour la première étape, une seule destination, jamais de waypoints (D-032).
• maps-url (API) et le repli hors connexion de useGoActions().directions() (mobile) appellent tous deux stepMapsUrl : une seule définition. Les deux copies walkingMapsUrl (API et mobile) disparaissent.
• Le tableau des modes recopie mappings.transitModes.modes[].maps de packages/tokens/generated/tokens.json, vérifié identique, avec un commentaire qui le dit : le paquet tokens n'exporte pas cette table (seulement le thème et les icônes). Copie acceptée pour ce ticket ; le risque d'écart est signalé à l'Inbox.

Fixes #510
Écrans : E-07
Dépendance : aucune

Comment vérifier

Les trois premiers commits ont été écrits par un agent opencode (GLM) et sont gardés tels quels ; le quatrième corrige le test API du mode, qui prenait son attendu dans travelModeOf, la fonction testée, et ajoute le formatage Prettier que GLM n'avait pas passé (pnpm lint lance prettier --check .).

• packages/orchestration/src/maps.test.ts : chaque mode, première étape à pied, trajet sans mode à pied, une seule destination.

• apps/api/src/routes/planned-go.test.ts : un parcours dont les trois trajets sont à vélo, en métro et en voiture donne walking vers la première étape, puis bicycling, transit et driving (valeurs littérales) ; la destination est celle de l'étape, sans waypoints ; chaque URL de l'API est égale à stepMapsUrl appliquée aux étapes du même PlannedRoute, ce que l'app écrit hors connexion (critère « URL hors connexion identique »).

• apps/mobile/src/go/progress.test.ts : la sortie fictive (testPlanned.ts, un trajet à vélo puis en métro) donne les URL exactes attendues.

• Contrôle par mutation en local : avec metro → driving dans maps.ts, le test API échoue (l'ancien test l'aurait laissé passer).

• pnpm lint && pnpm typecheck && pnpm test verts en local — lint, Prettier et typecheck verts sans cache (pnpm turbo run lint typecheck --force) ; tests de l'orchestration, des fichiers API du planning et du Go, du dossier go mobile (vitest et jest) verts. Suite complète laissée à la CI (charge machine trop haute pour la suite API entière).

• Testé sur iOS / Android (préciser) — si mobile : non. Le changement mobile ne porte que sur la construction de l'URL hors connexion, sans rendu ; pas d'écran modifié, pas de test à 150 % de texte.

Formatage mécanique : oui, dans le quatrième commit (useGo.ts : import regroupé par Prettier ; planned-go.test.ts reformaté avec la réécriture du test).

Risque

Niveau : 1 — construction d'une URL externe à partir des données du planning de l'appelant, sans accès, stockage ni entrée non fiable nouveaux.

Taille : 4 commits, +97 / −0, +51 / −37, +29 / −24, +30 / −25 lignes, tests compris.

Revue OWASP : non déclenchée (pas d'accès, de configuration, d'authentification ni de requête nouvelle ; la destination vient du snapshot du planning de l'appelant, encodée par encodeURIComponent).

Retour arrière

Revert de la PR suffisant : aucune migration ni donnée persistée.

🤖 Generated with Claude Code

[PaulThiberville]

Plan et décisions : les trois commits GLM sont gardés tels quels. La règle vit dans packages/orchestration (déjà dépendance de l'API et du mobile, qui l'importe pour computeTimeline) plutôt que dans packages/shared, avec la timeline et les trajets. La table des modes y est recopiée de mappings.transitModes faute d'export du paquet tokens. Le quatrième commit remplace l'attendu calculé par travelModeOf par des valeurs littérales et une égalité exacte avec stepMapsUrl sur les étapes du même planning, qui est la preuve du critère « URL hors connexion identique à celle de l'API ».