: les sauvegardes changent de granularité, du conteneur au projet

v0.18.0-beta

Changement majeur

⚠️ BREAKING : les sauvegardes changent de granularité, du conteneur au projet. run-backup et restore-backup visaient jusqu'ici une app individuelle (une ligne de sauvegarde par conteneur du projet, ex. "db", "web", "cache"), alors qu'un conteneur est reconstructible depuis son image et n'a rien de significatif à sauvegarder. La commande dorénavant : (1) archive les données réelles de chaque volume Docker nommé du projet (via un conteneur jetable qui monte le volume et le tar - avant, seul le dossier compose était archivé, jamais les données des volumes eux-mêmes), (2) dump la base managée si le projet en a une, (3) regroupe le tout dans une seule archive tar.gz par run. La restauration réapplique le bundle puis relance TOUS les services du projet (docker compose restart), plus seulement l'app ciblée. Le hub ne référence plus appSlug sur ces deux commandes ; un ancien agent qui recevrait le nouveau payload ignorerait volumeNames (champ inconnu) et tenterait un dump DB seul si présent, sans échouer bruyamment - mais la mise à jour de l'agent reste nécessaire pour un backup complet.
Correctif (auto-review avant merge) : run-backup/restore-backup ne prenaient plus aucun verrou. Le mutex par commande était indexé uniquement sur appSlug ; ces deux commandes n'en envoient plus (elles sont désormais scopées projet), donc elles tournaient sans aucune exclusion mutuelle - deux restaurations concurrentes sur le même projet pouvaient interférer sur les mêmes volumes. Le dispatcher verrouille maintenant aussi sur projectSlug (verrou projet pris avant le verrou app, ordre fixe partout, pas de deadlock possible).
Correctif (auto-review avant merge) : une restauration sur une archive corrompue/étrangère se rapportait comme réussie. Si aucune entrée de l'archive ne correspondait au format attendu (volume-*.tar.gz ou db.sql.gz - imbrication inattendue, archive tronquée, format différent), restore-backup continuait quand même et renvoyait un succès avec zéro volume/BDD restauré. La commande échoue désormais explicitement dans ce cas.