Precision configurable des distances (arrondi superieur 0/1/2 decimales)

- Nouveau parametre global Precision_Distance (sous-menu Application de la
  Page_Parametrage, entre Compte et Vehicules), persiste via une entite
  singleton ParametresApplication, expose par GET/PUT /api/parametres-application
- Arrondi superieur (ceiling) applique a l'affichage et aux agregats : trajet
  simple, aller/retour (arrondi puis doublement), totaux jour/mois/annee,
  carte, export PDF et bareme kilometrique - jamais a la distance brute stockee
- Refonte du Montant_Previsionnel : le montant mensuel (80%) porte desormais
  sur le seul mois affiche (tranche determinee par le cumul annuel) ; nouvelle
  ligne Montant_Previsionnel_Annuel (100%, sans minoration, sur le cumul)
- Backend : PrecisionDistanceService (ArrondirDistance), integration dans
  ResumeService/TotauxService/RemboursementService/MontantRegleService,
  migration EF Core ; 7 tests de propriete (FsCheck) + tests existants, 62/62 verts
- Frontend : ParametresApplicationService (signal partage), composant de
  parametrage, fonction miroir arrondirDistance, adaptation de la liste des
  trajets, du panneau des totaux, de la carte et des montants regles
- Specs : nouvelle spec precision-distances-km (requirements/design/tasks) ;
  mise a jour de requirements.md, design.md et design-requirements.md de
  schotziad-km-tracker (Requirement 22, renvois croises, Montant_Previsionnel)
- Suppression du fichier chromium .deb suivi par erreur dans le depot

.kiro/specs/schotziad-km-tracker/design-requirements.md

@@ -8,7 +8,9 @@ Ce document rassemble les **exigences techniques** dérivées des exigences fonc
 
 Ces exigences sont destinées à être définies et arbitrées **conjointement par le PO business et le PO IT**, dans un second temps, une fois le besoin fonctionnel stabilisé. Elles peuvent évoluer sans remettre en cause le besoin métier tant que le comportement observable décrit dans `requirements.md` est respecté.
 
-Le document est organisé **en miroir** des exigences de `requirements.md` : chaque section reprend le même numéro et le même titre suivi de « — aspects techniques », afin de faciliter les références croisées. Seules les exigences comportant effectivement des critères techniques apparaissent ici. Les exigences purement métier (Requirements 4, 13, 18) ne figurent pas dans ce document.
+Le document est organisé **en miroir** des exigences de `requirements.md` : chaque section reprend le même numéro et le même titre suivi de « — aspects techniques », afin de faciliter les références croisées. Seules les exigences comportant effectivement des critères techniques apparaissent ici. Les exigences purement métier (Requirements 4, 18) ne figurent pas dans ce document.
+
+> **Précision des distances** : les aspects techniques du paramètre Precision_Distance (endpoint, entité, formule d'arrondi) sont résumés au Requirement 22 ci-dessous, avec renvoi vers la spec séparée `precision-distances-km` (`design.md`) pour le détail complet (DTOs, service, migration).
 
 ---
 
@@ -23,6 +25,7 @@ Le document est organisé **en miroir** des exigences de `requirements.md` : cha
 - **JWT** : JSON Web Token signé (HS256) émis par le Backend à la connexion, portant l'identifiant du Compte et une durée de validité configurable (12 heures par défaut). Support technique de la Session définie dans `requirements.md`.
 - **Cache_Adresses** : La table de base de données stockant les couples (adresse textuelle normalisée BAN, coordonnées géographiques) des adresses déjà saisies, soumise à une politique de rétention LRU.
 - **Mermaid** : Syntaxe de définition de diagrammes (ex. `graph TB`) rendue graphiquement lors de l'affichage des Documents_Specification.
+- **ParametresApplication** : L'entité backend singleton (une seule ligne, `Id = 1`, sur le modèle de `Profil`/`Compte`) portant la colonne `PrecisionDistanceKm`, contrainte par un CHECK SQL `IN (0, 1, 2)`. Détaillée intégralement dans la spec `precision-distances-km`, `design.md`.
 
 ---
 
@@ -165,6 +168,16 @@ Le document est organisé **en miroir** des exigences de `requirements.md` : cha
 
 ---
 
+### Requirement 13: Barème kilométrique et indication de versement — aspects techniques
+
+> Exigence fonctionnelle : voir `requirements.md`, Requirement 13.
+
+#### Acceptance Criteria
+
+1. WHEN le Backend calcule le Montant_Previsionnel_Mensuel ou le Montant_Previsionnel_Annuel, THE Backend SHALL utiliser des distances déjà arrondies selon Precision_Distance (et non les distances brutes), conformément à la spec `precision-distances-km`, Requirements 6 et 7.
+
+---
+
 ### Requirement 14: Montant réglé mensuel et régularisation annuelle — aspects techniques
 
 > Exigence fonctionnelle : voir `requirements.md`, Requirement 14.
@@ -261,3 +274,17 @@ Le document est organisé **en miroir** des exigences de `requirements.md` : cha
 
 1. THE Frontend SHALL masquer entièrement la barre de navigation (y compris l'Avatar_Utilisateur) sur les pages non authentifiées (connexion, inscription, mot de passe oublié, réinitialisation), MÊME SI un jeton résiduel expiré ou invalide est encore présent localement, la présence locale d'un jeton ne garantissant pas la validité réelle de la Session sur ces pages.
 2. THE Frontend SHALL proposer, sur chaque champ de saisie d'un Mot_De_Passe (connexion, inscription, réinitialisation, changement de mot de passe), un contrôle permettant de basculer l'affichage entre masqué et visible, afin que l'utilisateur puisse vérifier la saisie ; ce contrôle SHALL présenter un rendu visuel identique à celui des autres champs de saisie du formulaire.
+
+---
+
+### Requirement 22: Précision configurable des distances — aspects techniques
+
+> Exigence fonctionnelle : voir `requirements.md`, Requirement 22. Détail complet (DTOs, service, migration) dans la spec `precision-distances-km`, `design.md`.
+
+#### Acceptance Criteria
+
+1. THE Backend SHALL exposer les opérations de lecture et de modification de Precision_Distance via un endpoint `GET/PUT /api/parametres-application`, protégé par le même filtre d'autorisation JWT global que les autres endpoints de données, retournant 401 en l'absence de jeton valide.
+2. IF le Backend reçoit sur `PUT /api/parametres-application` une valeur de Precision_Distance différente de 0, 1 ou 2, THEN THE Backend SHALL retourner une erreur HTTP 400.
+3. WHEN le Backend traite avec succès une requête sur `GET/PUT /api/parametres-application`, THE Backend SHALL retourner un code HTTP 200 accompagné de la configuration courante.
+4. THE Backend SHALL persister Precision_Distance dans une entité singleton `ParametresApplication` (une seule ligne, `Id = 1`), avec une contrainte CHECK SQL garantissant `PrecisionDistanceKm IN (0, 1, 2)`.
+5. THE Backend SHALL calculer toute distance arrondie selon la formule `Ceiling(distanceBrute × 10^precision) / 10^precision`, appliquée à la lecture, jamais à l'écriture de la colonne `Trajet.Distance`.