docs: rotation des secrets Gitea effectuée + CLI CapRover documenté

- INTERNAL_TOKEN, LFS_JWT_SECRET et mot de passe MySQL rotés le 2026-09-23
- DB_PASSWD CapRover resynchronisé, service redémarré et vérifié
- Confirmation que les env vars CapRover de l'app gitea (DB_PASSWD etc.)
  ne sont pas au format GITEA__section__clé donc inertes pour app.ini
- Documentation de l'installation/usage du CLI caprover via fnm

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

CLAUDE.md

@@ -78,6 +78,21 @@ Aucun service en erreur connu (vérifié 2026-02-19). `mail` tourne correctement
 
 **Prérequis** : définir `CAPROVER_PASSWORD` dans `.env` (voir `.envrc`)
 
+### CLI CapRover (alternative à l'API brute)
+
+Installé localement via `fnm` (Node géré sans toucher au système) :
+```bash
+curl -fsSL https://fnm.vercel.app/install | bash   # une seule fois
+fnm install --lts && fnm use lts-latest
+npm install -g caprover
+caprover login    # à faire soi-même dans un vrai terminal (TTY requis pour le mot de passe)
+```
+Ensuite : `caprover list` (machines connectées), `caprover api -n <nom-machine> -t /chemin/api -m GET -d '{}'` pour des appels génériques (toujours passer `-d` même vide, sinon prompt interactif qui plante sans TTY).
+
+Endpoints utiles :
+- `GET /user/apps/appDefinitions` → liste toutes les apps avec `envVars`, `volumes`, `ports`, etc.
+- `POST /user/apps/appDefinitions/update` (payload : `appName` + les champs à conserver/modifier) → met à jour la config d'une app **sans redéployer l'image** (mais redémarre le service)
+
 ## Gitea — détails techniques
 
 - **Containers Docker** (Swarm) : `srv-captain--gitea.1.*` (gitea/gitea:1.25.4) + `srv-captain--gitea-db.1.*` (mysql:5.7)
@@ -88,6 +103,7 @@ Aucun service en erreur connu (vérifié 2026-02-19). `mail` tourne correctement
   - Logs applicatifs : `/data/gitea/log/gitea.log` (rotation quotidienne en `.gz`)
 - **Réseau** : container Gitea sur `captain-overlay-network`, IP interne observée `10.0.1.75`. Le reverse-proxy CapRover (`captain-nginx`) apparaît côté Gitea sous l'IP `10.0.1.105` pour toutes les requêtes publiques (pas d'IP client réelle sans config `X-Forwarded-For`/trusted proxies).
 - **Connexion à la base MySQL depuis le host/container** : passer par `-h 127.0.0.1` (TCP), pas par défaut socket local (`localhost`) — le grant MySQL de l'utilisateur `gitea` ne couvre que `%`/TCP, pas `localhost`.
+- **Variables d'env CapRover de l'app `gitea`** (vérifié via `docker service inspect srv-captain--gitea`) : `DB_HOST`, `DB_PASSWD`, `DB_TYPE`, `DB_USER`, `RUN_MODE`. ⚠️ Aucune n'est au format `GITEA__<section>__<clé>` attendu par l'image officielle pour réinjecter dans `app.ini` au démarrage — elles sont donc **inertes** pour Gitea (c'est `app.ini` dans le volume qui fait foi). En cas de rotation de secret (mot de passe DB notamment), mettre à jour `app.ini` + redémarrer suffit fonctionnellement ; penser quand même à resynchroniser `DB_PASSWD` côté CapRover pour ne pas laisser une copie obsolète du secret.
 - **⚠️ Voir `incidents/2026-09-14-gitea-cryptominer.md`** : l'API interne Gitea (`/api/internal/manager/add-logger`) a été exploitée pour injecter des `packObjectsHook` malveillants dans `.gitconfig`. Toujours vérifier ce fichier ne contient pas d'entrées `[uploadpack] packObjectsHook` inattendues.
 
 ## Suivi des tâches