fix(backend,ci): repare trois angles morts de la surveillance de derive

Revue de la branche : trois defauts empechaient la surveillance de tenir ce qu'elle annonce.

- `evaluate()` gardait les microsecondes de `now()` dans `window_end`, la cle de
  `uq_drift_report_window`. Deux executions ne collidaient donc jamais et l'index ne
  dedoublonnait rien, contrairement a ce qu'affirmaient l'ADR 0011, 20-backend et le docstring
  du DAG. L'instant de reference est desormais tronque a l'heure.
- Un site qui cessait d'etre score disparaissait du rapport : la liste des sites ne venait que
  de la fenetre recente. La panne que cette surveillance existe pour dire etait exactement
  celle qu'elle taisait. La fenetre de reference entre maintenant dans l'union, et le site
  recoit sa ligne `indetermine` a zero observation.
- Sans fenetre de reference, `_plafond` rendait `None` et le verdict tombait sur `stable`, une
  affirmation que la donnee ne portait pas. C'est `indetermine` desormais.

`ml.yml` ecoute `apps/backend/app/**` et non les seuls modeles : ce workflow est le seul a
jouer `-m chaine`, or la chaine traverse les endpoints, les services et les schemas jusqu'a
`GET /predictions`. Une PR touchant `predictions.py` ne declenchait pas le test qui l'assert.

Hygiene de tests : le nettoyage des fixtures API connait `drift_report` (cle etrangere RESTRICT
vers `site`), le test sans rapport rend ses overrides en teardown, `test_chaine_ml_api` compare
les `created_at` strictement (un `>=` passait aussi quand l'API resservait la premiere ligne),
et `test_data_integration` filtre sur le site seme au lieu de juger tout le contenu d'une
fenetre dans une base partagee.

Docs remises d'aplomb : sept revisions Alembic et non six, `derive.py` dans l'inventaire de
etl/README, et le diagramme de 20-backend gagne DriftService, le depot drift et sa treizieme
table.

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

@@ -81,14 +81,22 @@ modèle change n'est pas une dérive, c'est une régression de réentraînement.
 | Écrire le résultat dans `alert` | `ck_alert_source` et `ck_alert_type` bornent les valeurs autorisées, `alert.site_id` est `NOT NULL` et n'accueillerait donc pas la ligne globale, et toute alerte est ensuite relue par le moteur de recommandations, qui devrait apprendre une règle qui ne le concerne pas (ADR 0006). |
 | Une jauge Prometheus | `monitoring/` ne contient que des `.gitkeep` et aucun collecteur ne lit `/metrics` : une jauge que personne ne scrute n'est pas une preuve. Le calcul est de surcroît un traitement par lot, pas le processus qui sert l'API : la jauge disparaîtrait avec lui. |
 | Ne rien persister, journaliser seulement | La question posée à un jury est « comment savez-vous que le modèle se dégrade ? ». La réponse est une série dans le temps, pas une ligne de journal perdue avec le conteneur. Sans ligne écrite, l'endpoint n'a rien à lire et le test d'intégration rien à vérifier. |
-| Une tâche de plus dans le DAG `alertes` | La fenêtre fait 168 h : la recalculer chaque heure écrirait vingt-quatre lignes identiques par jour. Surtout, un échec de dérive ferait rougir `alertes` et laisserait croire que la détection a échoué. |
+| Une tâche de plus dans le DAG `alertes` | La fenêtre fait 168 h : la recalculer chaque heure écrirait vingt-quatre lignes par jour pour un verdict qui ne bouge pas à cette cadence. Surtout, un échec de dérive ferait rougir `alertes` et laisserait croire que la détection a échoué. |
 
 ## Conséquences
 
 - Une migration ajoute `drift_report`. Son idempotence passe par un **index unique à
   `coalesce(site_id, '')`** et non par une `UniqueConstraint` : deux lignes globales ont toutes
   deux `site_id` à NULL, et NULL n'est égal à rien, pas même à lui-même. Même forme que
-  `uq_reading_source`.
+  `uq_reading_source`. Cet index n'a de sens que parce que `evaluate()` **tronque son instant de
+  référence à l'heure** : avec les microsecondes de `now()`, deux exécutions ne porteraient jamais
+  la même clé et l'index ne dédoublonnerait rien.
+- **Sans fenêtre de référence, le verdict est `indetermine`, pas `stable`.** Au premier
+  lancement, et après tout trou d'ingestion de plus de 168 h, il n'y a rien à quoi comparer :
+  annoncer `stable` serait affirmer ce que la donnée ne dit pas.
+- **Un site présent dans la fenêtre de référence et absent de la récente reçoit sa ligne**, à
+  zéro observation. Un site qui cesse d'être scoré est exactement la panne que cette surveillance
+  existe pour dire : le taire en ne produisant aucune ligne serait l'inverse du besoin.
 - `GET /api/v1/monitoring/drift` est réservé à partir du rôle `operateur` : c'est l'opérateur
   qui agit sur un pipeline dégradé, pas l'administrateur de comptes. La route est classée dans
   `tests/api/acces.py`, donc couverte gratuitement par la matrice de rôles rejouée avec de vrais