L'écran d'administration du front proposait des boutons Modifier et
Désactiver qui n'appelaient rien (console.log côté client), faute
d'endpoints correspondants. Ajoute POST/PUT/DELETE sur /services,
/categories, /contacts et /monitorings, tous protégés par require_admin.
Deux garde-fous métier :
- la suppression d'un service ou d'une catégorie est refusée (409) tant
que des monitorings ou contacts y sont rattachés, avec le décompte
dans le message, plutôt que de laisser remonter une violation de clé
étrangère ;
- un monitoring est désactivé (actif = 0) et jamais supprimé, car
TABLE_FINAL référence son identifiant et l'historique doit rester
consultable.
Le rôle utilisateur est désormais typé par l'enum UserRole : Pydantic
le valide seul (422), ce qui supprime les deux contrôles manuels
dupliqués dans create_user et update_user.
Tests : 8 -> 16. Couvre la validation par enum, le refus 409 sur
rattachement, le 403 pour un non-administrateur et la désactivation
logique du monitoring.
VUE_CONSO ne rattache pas tous les services/catégories des référentiels
SERVICE et CATEGORIE à un monitoring actif (ex. "Business Intelligence").
Les proposer tels quels dans les filtres du dashboard menait à un écran
vide. Le nouvel endpoint renvoie un SELECT DISTINCT service, categorie
sur VUE_CONSO, avec les combinaisons pour permettre un filtrage en
cascade côté frontend.
Ajoute un test dédié et régénère docs/openapi.json.