fix(grafana): startupProbe + liveness grace pour les migrations SQLite

Grafana tourne en SQLite sur emptyDir → migration complète du schéma à chaque
démarrage de pod, > 160 s sur Raspberry Pi. La liveson (initialDelay 60 + 10×10s)
tuait Grafana en pleine migration → CrashLoop du nouveau pod à chaque rollout
(révélé par le rollout du dashboard prospection). Ajoute une startupProbe (~10 min)
et relève failureThreshold de la liveness (filet si le chart n'expose pas startupProbe).

Co-Authored-By: Claude Opus 4.8 <[email protected]>

grafana/values.yaml

@@ -69,13 +69,26 @@ grafana: &grafana_config
       path: /api/health
       port: 3000
 
+  # Base Grafana en SQLite sur emptyDir → migration complète du schéma à CHAQUE démarrage du
+  # pod, lente sur Raspberry Pi (> 160 s). Sans garde suffisante, la liveness tuait Grafana en
+  # pleine migration → CrashLoop au moindre rollout. startupProbe : ~10 min avant d'armer la
+  # liveness. failureThreshold de liveness relevé aussi (filet de sécurité si le chart n'expose
+  # pas startupProbe). Fix pérenne : DB persistante (PVC) ou externe (postgres) — hors scope ici.
+  startupProbe:
+    httpGet:
+      path: /api/health
+      port: 3000
+    initialDelaySeconds: 30
+    periodSeconds: 10
+    failureThreshold: 60
+
   livenessProbe:
     httpGet:
       path: /api/health
       port: 3000
     initialDelaySeconds: 60
     timeoutSeconds: 30
-    failureThreshold: 10
+    failureThreshold: 60
 
   ## Use an alternate scheduler, e.g. "stork".
   ## ref: https://kubernetes.io/docs/tasks/administer-cluster/configure-multiple-schedulers/