: backups change granularity, from container to project

v0.18.0-beta

Breaking change

⚠️ BREAKING: backups change granularity, from container to project. run-backup and restore-backup targeted an individual app until now (one backup row per project container, e.g. "db", "web", "cache"), while a container is rebuildable from its image and has nothing meaningful to back up. The command now: (1) archives the real data of every named Docker volume in the project (through a throwaway container that mounts the volume and tars it — before, only the compose folder was archived, never the volumes' data itself), (2) dumps the managed database if the project has one, (3) gathers it all into a single tar.gz archive per run. Restoring reapplies the bundle then restarts ALL of the project's services (docker compose restart), no longer just the targeted app. The hub no longer references appSlug on these two commands; an older agent receiving the new payload would ignore volumeNames (unknown field) and attempt a DB dump alone if present, without failing loudly — but updating the agent remains necessary for a complete backup.
Fix (self-review before merge): run-backup/restore-backup no longer took any lock. The per-command mutex was keyed on appSlug alone; these two commands no longer send one (they are now project-scoped), so they ran with no mutual exclusion at all — two concurrent restores on the same project could interfere on the same volumes. The dispatcher now also locks on projectSlug (project lock taken before the app lock, fixed order everywhere, no deadlock possible).
Fix (self-review before merge): a restore from a corrupt or foreign archive reported itself as successful. If no entry in the archive matched the expected format (volume-*.tar.gz or db.sql.gz — unexpected nesting, truncated archive, different format), restore-backup carried on anyway and returned success with zero volumes/databases restored. The command now fails explicitly in that case.