fix(ml): borne la fenetre de scoring a l'instant demande, pour que --now rejoue l'historique

`load_recent_from_database` n'avait qu'une borne basse. `build_scoring_frame` repartait donc de
la derniere lecture de toute la table quel que soit `--now` : `target_at` valait toujours
"fin du jeu + 1h", et `_age = instant - derniere_lecture` devenait negatif, ce qui passait le
seuil de peremption sans rien signaler.

Consequence concrete : sur le jeu historique, arrete au 31/12/2024, aucune boucle de rattrapage
ne pouvait produire une prevision dont le realise existe deja. La surveillance de derive livree
par la migration precedente n'aurait donc rien eu a comparer en demonstration.

`until` est desormais obligatoire sur ce chargeur, ce qui interdit de l'oublier, et le mode CSV
filtre symetriquement. En exploitation rien ne change, aucune lecture n'etant posterieure a
l'heure courante.

docs/ML-START.md

@@ -102,11 +102,13 @@ Trois contraintes de cohérence sont portées par la base et non par le code app
 sont vérifiées depuis le code qui écrit par `ml/tests/test_score_integration.py`, sur une vraie
 base : un double ne prouverait rien d'une contrainte SQL.
 
-**Limite connue de `--now`.** L'option décale l'instant de référence, pas la fenêtre de lecture :
-`load_recent_from_database` n'a pas de borne haute et `build_scoring_frame` part toujours de la
-dernière lecture connue. `target_at` vaut donc « dernière lecture du jeu + 1 h » quelle que soit
-la valeur passée, et aucune boucle de rattrapage ne peut fabriquer de paires prévu/réalisé sur un
-jeu figé.
+**`--now` borne la fenêtre des deux côtés.** `load_recent_from_database` exige un `until` autant
+qu'un `since`, et le scoring lui passe l'instant de référence. Sans cette borne haute,
+`build_scoring_frame` repartait de la dernière lecture de toute la table quelle que soit la valeur
+demandée : `target_at` valait toujours « fin du jeu + 1 h », et l'âge de la dernière lecture
+devenait négatif sans franchir le seuil de péremption. Rejouer le scoring sur des instants passés
+produit désormais des prévisions dont le réalisé existe déjà, ce dont la surveillance de dérive a
+besoin pour se démontrer sur un jeu figé.
 
 ### `model_reference` est un hachage, pas un nom de fichier
 

docs/adr/0011-surveillance-de-derive-dans-le-backend.md

@@ -98,9 +98,15 @@ modèle change n'est pas une dérive, c'est une régression de réentraînement.
 - La CLI sort en code non nul sous `--fail-on-drift` seulement. Par défaut, constater une dérive
   n'est pas un échec d'exécution.
 
-## Limite connue
+## Effet de bord assumé sur le pipeline
 
-`enervision_ml.score --now` ne rejoue pas l'historique : `load_recent_from_database` n'a pas de
-borne haute, et `build_scoring_frame` part toujours de la dernière lecture connue. Aucune boucle
-de rattrapage ne peut donc fabriquer de paires prévu/réalisé sur des données figées, et la
-dérive répond `indetermine` tant que le scoring n'a pas tourné plusieurs fois en exploitation.
+La dérive n'a de matière que si des paires prévu/réalisé existent. Or `enervision_ml.score --now`
+ne rejouait pas l'historique : `load_recent_from_database` n'avait pas de borne haute et
+`build_scoring_frame` repartait de la dernière lecture connue, si bien que `target_at` valait
+toujours « fin du jeu + 1 h » et que l'âge de la dernière lecture devenait négatif sans franchir
+le seuil de péremption. Sur le jeu historique, figé au 31/12/2024, aucune boucle de rattrapage
+n'aurait donc rien produit de vérifiable.
+
+`until` est devenu obligatoire sur ce chargeur, et le scoring lui passe son instant de référence.
+Le comportement en exploitation ne change pas, aucune lecture n'étant postérieure à l'heure
+courante ; seul le rattrapage sur données passées devient possible.