D21 — Un seul S3 pour la prod et le staging

• Contexte : chaque namespace avait son propre SeaweedFS. Celui du staging occupait de la RAM et un volume de 10 Gio pour des buckets presque vides : le staging lisait déjà media et les embeddings dans le S3 de snag-prod, et le Job du datalake staging écrivait dans un S3 où le catalogue Lakekeeper ne regarde jamais.
• Décision (owner, 2026-11-07) : un seul SeaweedFS, celui de snag-prod. Le staging n'a plus de S3 à lui ni d'explorateur files-staging ; il garde des buckets et des identités à lui :
  • user-files-staging pour les exports et imports de l'API, en lecture, écriture et liste sur ce bucket seulement ;
  • datalake-staging en lecture et liste seulement sur datalake et lakehouse.
• Justification : moins de RAM et de disque sur un cluster déjà juste. Un seul S3 à sauvegarder, surveiller et sécuriser. Une seule copie de media, ce qui était déjà le cas. Les identités par bucket gardent l'isolation : le staging ne peut ni lire les fichiers des utilisateurs prod, ni écrire dans media, user-files, mlflow ou le lac.
• Conséquences :
  • une panne ou une saturation du S3 touche les deux environnements, et donc media.snag-app.io, que l'app mobile utilise : un test de charge du staging ne vise jamais le S3 ;
  • ajouter les identités staging demande un redémarrage du S3 prod, qui coupe media.snag-app.io environ une minute (à faire à une heure creuse) ;
  • une répétition staging d'un job du datalake qui écrit s'arrête à sa première écriture : les exécutions qui écrivent se font depuis snag-prod ou depuis le laptop ;
  • les enregistrements DNS media-staging et files-staging sont à supprimer chez Cloudflare.
• Statut : adoptée. Références : gitops PR « un seul S3 » ; ops/s3/add-staging-identities.sh ; docs/data-layout.md.