fix(etl): borne le DAG alertes sur son pire cas et couvre sa seconde commande en CI

`execution_timeout` plafonne une tentative, pas la tâche. Avec deux reprises, quinze
minutes par tentative autorisaient quarante-neuf minutes par tâche et quatre-vingt-dix-huit
pour l'enchaînement, quand le commentaire annonçait une somme tenant sous le pas horaire.
Le plafond passe à cinq minutes, ce qui borne le pire cas à trente-huit minutes, et le test
d'intégrité calcule désormais ce pire cas plutôt que la somme des plafonds : reprises et
délais d'attente compris, c'est la durée qu'un `max_active_runs=1` fait payer à l'exécution
suivante.

La CI vérifie aussi `app.cli generate-recommendations --help` sans réseau. C'est la seconde
commande du DAG, et son import tire FastAPI, les repositories et les services, donc une part
de l'environnement `/opt/backend` que la détection seule ne touche pas.

`10-infra.md` nomme enfin ce que le décalage de quinze minutes ne garantit pas : le plafond
de `ml_score` valant trente minutes, un scoring qui déborde prive la règle `anomaly` de la
prédiction de l'heure, qu'elle ne retrouvera au passage suivant que si sa fenêtre la couvre
encore.

etl/airflow/dags/alertes.py

@@ -26,9 +26,9 @@ COMMANDE_BACKEND = "cd /opt/backend && env -u VIRTUAL_ENV uv run --no-sync pytho
 # `uq_alert_source_reference` et `uq_recommendation_alert_rule`) : reprendre ne duplique rien.
 TENTATIVES = 2
 DELAI_ENTRE_TENTATIVES = timedelta(minutes=2)
-# La somme des deux plafonds reste sous le pas horaire : une exécution pendue ne doit pas
-# empiéter sur la suivante.
-PLAFOND_PAR_TACHE = timedelta(minutes=15)
+# `execution_timeout` vaut par tentative : c'est le pire cas des deux tâches enchaînées, reprises
+# et délais compris, qui doit tenir sous le pas horaire. Les tests d'intégrité en font le calcul.
+PLAFOND_PAR_TACHE = timedelta(minutes=5)
 
 with DAG(
     dag_id="alertes",