Vaultwarden: migrer vaultwarden-pvc de cephfs vers ceph-rbd

## Contexte

`vaultwarden-pvc` (5Gi, RWX, storageClass `cephfs`) backe une simple base SQLite pour un déploiement single-replica. RWX n'est pas réellement nécessaire — RWO/`ceph-rbd` conviendrait.

## Historique des incidents (mounts CephFS coincés)

- **2026-08-06** : erreurs de login "no healthy upstream", `r2d2 unable to open database file` dans les logs. Fix court terme : `kubectl rollout restart deployment vaultwarden -n vaultwarden`.
- **2026-08-25** : "upstream request timeout" au login SSO Authentik. Même boucle `r2d2 unable to open database file`, plus un événement `FailedMount` actif (`mkdir ... file exists`) — le mount CSI était réellement coincé sur `k8s-shared-worker-6` (nodeplugin cephfs redémarré 4x, dernier redémarrage 41h avant). Fix : `umount -l` du mount per-pod + du globalmount partagé dans le pod `csi-cephfsplugin` concerné, puis `kubectl delete pod` pour forcer un re-stage.

C'est la 3e récurrence de ce type de panne sur cette PVC — le pattern racine (sessions client CephFS kernel qui corrompent, cascade CSI) est documenté et déjà résolu pour `forgejo`/`nextcloud` (PRs #289/#290) et `campusparent` (PRs #345/#350).

## Ce qu'il faut faire

Appliquer le même pattern de migration live (bump `instances`/scale + switch `storageClass: cephfs → ceph-rbd`, laisser la donnée se resynchroniser, basculer, nettoyer) que pour campusparent — adapté ici à un `Deployment` simple (pas un CNPG cluster) : provisionner une nouvelle PVC `ceph-rbd`, copier la base SQLite, re-pointer le déploiement, supprimer l'ancienne PVC cephfs.

Runbook de référence pour le contexte CSI cephfs : `runbooks/forgejo-cephfs-recovery.md`.