Specs : rattrapage de l'écart avec le code + règle de synchro continue

Aligne requirements.md et design.md sur l'état réel du code (écart accumulé
depuis le 14/09 en mode dev direct).

requirements.md :
- Intro : compte unique authentifié (au lieu de « sans authentification ».
- Glossaire : Compte, Adresse_Email, Mot_De_Passe, Session, JWT,
  Jeton_Reinitialisation, Aller_Retour, Distance_Effective.
- Exigence 1 : case Aller/Retour. Exigence 10 : dénomination véhicule.
- Exigence 12 : refonte consultation par mois (sélecteur année/mois, liste
  mensuelle groupée par jour repliable, nav jour bornée aux jours avec trajets).
- Exigence 13 : tranches de barème multiples (dernière illimitée, coef 3
  décimales) + recopie du dernier barème.
- Exigence 16 : onboarding relié à l'authentification.
- Nouvelles exigences 17 (Authentification) et 18 (Trajet aller/retour).

design.md :
- Overview + contraintes : compte authentifié, port 2202, Caddy externe HTTPS.
- Déploiement : compose (port 2202, JWT_SECRET_KEY obligatoire, e-mail/MailKit,
  AUTH_FRONTEND_BASE_URL), reverse-proxy Caddy externe, pas de UseHttpsRedirection.
- Nouvelle section « Évolutions majeures » : décisions d'architecture pour l'auth,
  l'onboarding 2 étapes, l'aller/retour, la consultation par mois, le barème
  multi-tranches, la dénomination véhicule et le recalcul ciblé des distances.

Ajoute .kiro/steering/spec-sync.md : règle de mise à jour des specs dans le même
commit que le code, à chaque évolution validée.

.kiro/steering/spec-sync.md

@@ -0,0 +1,38 @@
+# Synchronisation des specs avec le code
+
+## Règle
+
+Les documents de spécification du projet — `requirements.md` (exigences fonctionnelles au format EARS) et `design.md` (conception technique) — sont la source de vérité à long terme de ce projet. Ils DOIVENT rester alignés avec le code.
+
+À chaque évolution fonctionnelle ou technique validée par l'utilisateur (« ça fonctionne », « tu peux committer »), mettre à jour les specs concernées **dans le même commit** que le changement de code, avant de committer.
+
+## Portée
+
+- `requirements.md` : mettre à jour dès qu'un comportement observable change (nouvelle fonctionnalité, modification d'un critère d'acceptation, nouveau terme du glossaire, changement de portée comme l'ajout de l'authentification).
+- `design.md` : mettre à jour dès qu'une décision d'architecture, un modèle de données, un endpoint d'API ou un composant important change.
+- `tasks.md` : facultatif — c'est un journal d'implémentation, pas la source de vérité. Le mettre à jour seulement si l'utilisateur le demande.
+
+## Ce qui déclenche une mise à jour de spec
+
+- Nouvelle capacité (ex. aller/retour, authentification, consultation par mois).
+- Changement de contrat d'API (nouveau champ DTO, nouvel endpoint, changement de statut HTTP).
+- Nouveau modèle de données ou migration EF Core.
+- Changement de règle métier (ex. tranches de barème multiples, distance effective doublée).
+- Changement de portée du produit (ex. passage de mono-utilisateur sans compte à compte unique authentifié).
+
+## Ce qui ne déclenche PAS forcément une mise à jour
+
+- Ajustements purement cosmétiques (couleurs, espacements) sans exigence associée.
+- Refactorisations internes sans effet observable et sans changement de décision d'architecture.
+
+## Format
+
+- `requirements.md` : conserver le format EARS (WHEN / IF / WHILE / WHERE / THE ... SHALL). Numéroter les nouvelles exigences à la suite. Ajouter au glossaire tout nouveau terme.
+- `design.md` : conserver la structure existante (contraintes, décisions d'architecture, modèles, endpoints, composants). Documenter les décisions et les alternatives rejetées.
+- Valider le format avec l'outil de validation de spec après édition.
+
+## Workflow au moment du commit
+
+1. Implémenter le changement de code et le faire valider par l'utilisateur.
+2. Mettre à jour `requirements.md` et/ou `design.md` pour refléter le changement.
+3. Committer code + specs ensemble, avec un message décrivant les deux.