docs(vigilance): rectifier l'hypothèse load-balancer MF

L'observation initiale était à >20h UTC, hors fenêtres de publication MF
(04h/14h UTC). Diagnostic 60 fetches concurrents sans désynchro côté MF
→ l'origine est plus probablement notre cache / une requête transitoire.
On conserve la mitigation à 3 fetches concurrents pour rester safe, à
retirer si stabilité MF confirmée par observation suivie.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

src/lib/vigilance.ts

@@ -90,11 +90,16 @@ async function fetchOpendatasoft(): Promise<VigilanceSnapshot> {
 // Plus frais qu'Opendatasoft (publication directe) et couvre tous les domaines
 // (métropole, côtes, prochainement Outre-mer via /vigilanceom/flux/dernier).
 //
-// PIÈGE : le gateway MF (WSO2) load-balance entre plusieurs instances
-// qui peuvent être désynchronisées (constaté 2026-05-26 : ~60% des hits
-// retournaient le bulletin J-1 à 4h UTC, ~40% le bulletin J à 14h UTC).
-// Mitigation : on fait N fetches concurrents et on garde la réponse avec
-// le `update_time` le plus récent. N=3 atteint >95% de prob d'avoir le frais.
+// Historique : une désynchro avait été observée (snapshot Vigilance d'apparence
+// périmé) à >20h UTC le 2026-05-26 — loin des fenêtres de publication MF
+// (04h / 14h UTC). Vérification 2026-05-26 ~15h UTC (`scripts/check-mf-loadbalancer.mjs`,
+// 60 fetches concurrents) : 0 désynchro côté gateway WSO2. Origine plus probable
+// = bruit local (cache Valkey servant un vieux snapshot, ou requête transitoire),
+// pas le LB MF.
+//
+// Mitigation conservée prudemment : N fetches concurrents, on garde la réponse
+// avec le `update_time` le plus récent. Coût négligeable (1 cold fetch / TTL).
+// À retirer si on confirme plus tard que MF est stable (passer N à 1).
 
 const MF_PARALLEL_FETCHES = 3;
 const MF_ENDPOINT = '/public/DPVigilance/v1/cartevigilance/encours';