Aligner API, Orchestration, Modele-de-Donnees et Compte-et-Monetisation sur l'édition livrée par #48 #436

Contexte

Epic : #7
API › Création · Orchestration › Règles de cohérence · Modele-de-Donnees › route_revisions · Compte-et-Monetisation

Après la PR #420 (#48), le code a fixé des choix que le wiki ne porte pas (Inbox, 2026-10-14). Le wiki doit redevenir le miroir du produit réel, ou dire ce qu'il veut autrement (un écart devient alors un ticket de code).

Comportement attendu (DESIGN)

• API › Création : route GET /me/routes/:id (le parcours tel que l'éditeur l'affiche, sa révision s'il est publié) ; toutes les routes de l'éditeur répondent le même objet (OwnRoute de packages/shared), avec computed, warnings, errors ; 422 coherence_blocked avec la liste dans details.errors ; 409 conflict pour un déplacement refusé ou une édition impossible ; GET /me/routes paginé par curseur.
• Orchestration › Règles de cohérence : code bloquant missing_title (un brouillon sans titre ne se soumet pas).
• Bornes choisies par CODE faute de valeur au wiki, à valider ou corriger : description du parcours 2 000 caractères, titre d'étape 60, 30 étapes enregistrées au plus (soumission bloquée au-delà de 10), durée d'étape de 1 à 1 440 min à l'enregistrement, coût de 0 à 10 000 €.
• Modele-de-Donnees › route_revisions : colonnes livrées (route_id, author_id, status draft, pending, changes_requested, rejected, published, snapshot, submitted_at, decided_at, une révision ouverte par parcours) ; la révision est la copie de travail créée à la première modification, pas un instantané pris à la soumission.
• Compte-et-Monetisation : max_pending_routes compte aussi une révision en attente de relecture (commit f35f232) ; c'est la question ouverte de Documenter le 429 pending_routes et décider si une révision compte dans max_pending_routes #414, à clore avec ce ticket ou avec Documenter le 429 pending_routes et décider si une révision compte dans max_pending_routes #414.
• needs_fix (PR feat(api): créer, modifier et soumettre un parcours depuis l'éditeur #420, choix 5 et 7) : un parcours needs_fix se corrige en place, sans révision (needs_fix → pending), et sa resoumission le retire du public jusqu'à la décision ; published → needs_fix le retire aussi des profils, alors que la page dit qu'un parcours à corriger reste visible de tous. À confirmer ou corriger.
• Dépublication par l'auteur (choix 8) : elle abandonne (supprime) la révision ouverte.

Critères d'acceptation

• Les quatre pages citées décrivent le contrat livré par feat(api): créer, modifier et soumettre un parcours depuis l'éditeur #420, ou un écart voulu est consigné et ticketé
• Les bornes sont validées ou corrigées, avec leur valeur au wiki
• Entrée D-xxx au Design-Changelog