feat: add services page and API endpoints for service cost breakdown

- Implemented new API endpoints for fetching global services and service tenants details.
- Created a new services.html page with a sidebar for navigation and a chart for service costs.
- Updated frontend JavaScript to handle service data loading and rendering.
- Enhanced the dashboard with provider filtering options for AWS and Azure.
- Added a segmented toggle for selecting the date range for service costs.
- Improved styling for the sidebar and data tables.
- Refactored common utility functions for better reusability across pages.

README.md

@@ -252,39 +252,3 @@ simple-cost-dashboard/
 │       └── tenant.js             # logique page détail + graphes + drawer ressources
 └── deploy/                     # à venir : manifestes Kubernetes (voir TODO)
 ```
-
-## 9. À faire
-
-**Déploiement Kubernetes** (`deploy/`, pas encore créé) :
-- [ ] Manifeste `Deployment` pour le serveur web (readiness/liveness sur `/health`)
-- [ ] Manifeste `Service` + `Ingress`
-- [ ] Manifeste `CronJob` pour la collecte quotidienne, même image, commande surchargée
-- [ ] `PersistentVolumeClaim` pour `/data` (la base SQLite doit survivre aux redéploiements)
-- [ ] `Secret` Kubernetes pour `config.json` (credentials Azure notamment) plutôt qu'un ConfigMap en clair
-
-**Authentification** :
-- [ ] Basic Auth via l'Ingress (annotation nginx `auth-basic` + `Secret` `htpasswd`) — solution de départ validée
-- [ ] Bascule vers SSO Entra ID (app d'entreprise Azure + groupe) une fois le besoin confirmé — probablement via `oauth2-proxy` en sidecar/Ingress plutôt que dans le code de l'appli, pour ne pas coupler l'auth à FastAPI
-
-**Credentials AWS/Azure en environnement conteneurisé** :
-- [x] AWS : tranché pour des clés IAM dédiées par tenant (`access_key_id`/
-  `secret_access_key` dans `config.json`, droit `ce:GetCostAndUsage`
-  uniquement) plutôt que des profils `~/.aws` — les profils SSO ne
-  fonctionnent pas en conteneur (le refresh du token demande un
-  navigateur). Voir §2. Pas encore fait : créer ces clés IAM dédiées côté
-  AWS pour chaque tenant (elles n'existent pas encore, seuls des profils
-  SSO existent aujourd'hui) — et envisager `sts:AssumeRole` depuis une
-  identité unique si la rotation de 28+ clés IAM statiques devient trop
-  lourde à gérer.
-- [ ] `config.json` (les clés AWS et les `client_secret` Azure) doit passer
-  en `Secret` Kubernetes monté en volume une fois `deploy/` créé, pas en
-  ConfigMap.
-
-**Fiabilité / observabilité** :
-- [ ] Alerte (Slack/email) si un tenant est en échec de collecte plusieurs jours de suite — actuellement visible seulement en se rendant sur le dashboard
-- [ ] Sauvegarde régulière de la base SQLite (le PVC seul ne protège pas d'une corruption)
-- [ ] Limite de rétention ou archivage si le volume de la base grossit significativement à long terme (non urgent : le volume attendu reste faible)
-
-**Fonctionnel** :
-- [ ] Vérifier le rendu du dashboard avec de vraies données (actuellement testé uniquement sur la structure du code, pas sur un run réel bout-en-bout)
-- [ ] Décider si la page globale doit aussi permettre de filtrer/rechercher un tenant si leur nombre grossit beaucoup