feat(backend): moteur de règles de recommandations et route de génération

`recommendation` n'avait aucun écrivain : les quatre couches de lecture étaient
livrées, mais rien ne produisait de ligne. Le moteur comble ce trou.

Le catalogue `REGLES` vit dans `app/services/`, pas dans `ml/` : il lit `alert.type`,
`alert.severity`, `alert.value` et `alert.threshold`, sans modèle ni feature, et
s'appuie sur deux repositories existants. L'arbitrage avec l'ADR 0005, qui annonçait
#38 du côté ML, est tranché par l'ADR 0006.

Sept règles, cinq par type d'alerte et deux transverses (sévérité critique,
dépassement d'au moins 20 % du seuil), donc une à trois recommandations par alerte.
L'idempotence est portée par la base : `create_missing()` insère en
`ON CONFLICT DO NOTHING` sur `uq_recommendation_alert_rule`, ce qui supprime la
fenêtre entre un contrôle préalable et l'insertion. `rule_reference` devient de ce
fait une clé fonctionnelle, d'où le suffixe de version sur chaque référence.

Deux déclencheurs : `POST /api/v1/recommendations/generate` réservé `admin`, et
`python -m app.cli generate-recommendations` (cible `make recommendations`).

Limite connue : aucune source n'alimente `alert` aujourd'hui, ni détection interne
(#104) ni ingestion de l'API Mock. La route répond, le rapport reste à zéro, et la
chaîne s'allume sans retoucher le moteur le jour où les alertes existent.

Tests : 80 unitaires et API verts, plus 6 d'intégration dont l'idempotence jouée
contre PostgreSQL.

Closes #38

apps/backend/tests/api/acces.py

@@ -51,6 +51,7 @@ ROLE_MINIMUM: Final[dict[Route, Role]] = {
     ("GET", "/api/v1/alerts"): Role.LECTEUR,
     ("GET", "/api/v1/recommendations"): Role.LECTEUR,
     ("GET", "/api/v1/recommendations/{recommendation_id}"): Role.LECTEUR,
+    ("POST", "/api/v1/recommendations/generate"): Role.ADMIN,
     ("GET", "/api/v1/stats/summary"): Role.LECTEUR,
     ("GET", "/api/v1/readings"): Role.LECTEUR,
     ("GET", "/api/v1/predictions"): Role.LECTEUR,