feat(backups): restore volumes and environments from backups #337

Problem

A backup is only worth the restores it allows. Restoring in place destroys the current data, which may be the only good copy when the backup turns out wrong.

Proposed solution

Restore always creates new volumes and never overwrites one. Volume bindings (#335) make that possible.

• A volume: piquelctl backup restore APP ENV BACKUP --volume NAME creates a volume from the backup, then, once confirmed, stops the services mounting the name, rebinds it and redeploys. The replaced volume stays as a detached volume noting the restore that replaced it, until it is deleted. --no-swap only creates the volume, to inspect it first.
• An environment: --into ENV or --preview creates a new environment or preview from the backup: its generated secrets and every volume. Manual secrets come from the application's store as usual.
• By method: live, stop and snapshot volumes are written back file by file. A dump volume starts empty, its service initializes it, and the volume's restore command runs as a job reading the dump on its standard input before the service is started again.
• Generated secrets are restored with the volumes they belong to, so a restored database keeps working with its passwords.
• Restores are journal actions, visible in Events. A failed restore leaves the binding unchanged.

Distinct from #172, which restores a deployment and never touches data. The CLI noun (backup restore vs env restore) keeps the two apart.

Surfaces

API, CLI as above, and a restore flow on the dashboard's backup list with a confirmation step naming the services that stop.

Written with Claude Opus 5.5 in Claude Code (via T3 Code).