docs(tests): G2 is unreachable by design, document the health score steps

G3 invalidates the cache on every mutation, so a stale health list can no longer be staged. Also records why the score moves in steps of 10 and the per-category caps that can make early fixes invisible.

TEST_SCENARIOS.md

@@ -346,18 +346,23 @@ l'éditeur slideover : créer + éditer une entrée, ajouter/retirer des tags,
 
 ## G — Vault health (série 2026-07-25)
 
-### G1 · bouton *Fix* quand le changement d'entrée est annulé
+### G1 · bouton *Fix* quand le changement d'entrée est annulé ✅
 - **ACTION** : `A` ouverte + **dirty** → aller sur *Vault health* → cliquer **Fix** sur une **autre** entrée `B` → **Cancel** au message discard.
 - **ATTENDU** : **rien ne bouge**. `A` reste ouverte, son mot de passe reste **masqué**, aucun clignotement du bouton Generate.
 - Puis refaire → **Discard** : `B` s'ouvre, c'est **le mot de passe de B** qui est démasqué + sélectionné, et c'est le Generate de `B` qui pulse.
 - **Le focus RESTE sur le mot de passe** (~1 s après le clic, vérifier que le curseur n'a pas sauté sur le titre) : `openSlideOver` programme un focus différé de 80 ms sur `#soTitle`, neutralisé ici par `{ noFocus: true }`.
 - **Historique** : `openSlideOver` ne renvoyait rien, donc `openEntryForFix` continuait après une annulation et démasquait en clair le mot de passe de l'entrée **restée ouverte**.
 
-### G2 · *Fix* sur une entrée supprimée entre-temps
-- **ACTION** : ouvrir *Vault health* → dans un autre onglet de l'app, mettre à la corbeille une entrée listée → revenir sur health (sans Recompute) → **Fix** sur cette entrée.
-- **ATTENDU** : rien ne casse (l'éditeur ne s'ouvre pas, pas d'erreur JS). Avec G3 la liste devrait de toute façon être à jour.
+### G2 · *Fix* sur une entrée supprimée entre-temps — **sans objet**
+- **ACTION prévue** : ouvrir *Vault health* → mettre à la corbeille une entrée listée → revenir sur health sans *Recompute* → **Fix** sur cette entrée.
+- **Pourquoi c'est irréalisable** : G3 a rendu ce cas impossible à mettre en scène — le cache est invalidé à **chaque** mutation, donc revenir sur le tableau de bord recalcule toujours et l'entrée supprimée n'y figure plus. Le garde reste en place dans le code (`openEntryForFix` sort si `openSlideOver` renvoie `false`), il n'est simplement plus atteignable par l'interface.
 
-### G3 · le tableau de bord reflète les mutations
+### G4 · le score bouge par paliers de 10 — comportement attendu
+- **OBSERVÉ** : après correction de deux mots de passe, `30 → 40 → 50`.
+- **C'EST NORMAL** : le barème est `-5` par mot de passe **faible**, `-10` par **groupe de réutilisation**, `-2` par entrée **ancienne**, `-15` par entrée **compromise**. Corriger un mot de passe partagé par deux entrées casse le groupe → `+10`.
+- **Effet de bord à connaître** : chaque catégorie est **plafonnée** (`-40` faible, `-30` réutilisé, `-20` ancien, `-50` compromis). Au-delà de 8 mots de passe faibles, en corriger un ne change **rien** au score tant qu'on n'est pas repassé sous le plafond. Le plafond existe pour qu'une seule catégorie ne puisse pas écraser les autres, mais il rend les premières corrections invisibles quand le coffre en compte beaucoup.
+
+### G3 · le tableau de bord reflète les mutations ✅
 - **ACTION** : ouvrir *Vault health* (noter le score) → revenir à la liste → faire une mutation : **import**, **sync**, **suppression**, **batch delete**, **duplicate**, **restore**, ou **changement de master pw** → rouvrir *Vault health*.
 - **ATTENDU** : score et listes **recalculés** (les entrées supprimées ont disparu, les importées apparaissent) **sans** cliquer *Recompute*.
 - **Historique** : le cache n'était vidé qu'au lock / au save / via *Recompute* — après un import ou une suppression le dashboard restait figé sur l'état précédent.