Phase 8: back up & restore remote (agent) stacks (0.8.0)

- Agent: GET /agent/stacks/{id}/backup + POST /agent/stacks/restore (reuse
  backup_service). backup_service gains backup_basename/backup_filename helpers.
- Main proxy streams agent <-> main <-> destination (creds stay central):
  agent_service download_to_file/upload_file; routers/agents.py backup download,
  backup/push, restore upload, restore-from.
- Schedules: BackupSchedule.agent_id; schedule_service downloads from the agent
  when set; per-host filename prefix isolates retention across hosts.
- Frontend: agents api backup/restore; BackupButton/RestoreButton agent-aware
  (Backup on remote stack detail, Restore per host section); schedule form host
  selector (local or an online agent) + host shown on schedule rows.

Rough-verified (per request): py_compile, frontend tsc build, image imports
(main 99 / agent 16 routes). Full live agent round-trip to be tested post-deploy.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

README.md

@@ -5,7 +5,8 @@ as intuitive as Dockge, as capable as Portainer for Compose workflows.
 
 > **Status:** Phase 1 (Core) + Phase 2 (Volumes & GPU) + Phase 3 (Quality of
 > Life) + Phase 4 (Operations) + Phase 5 (Multi-host) + Phase 6 (Backup
-> destinations) + Phase 7 (Scheduled backups) complete.
+> destinations) + Phase 7 (Scheduled backups) + Phase 8 (Remote-stack backups)
+> complete.
 
 ## What works today (Phase 1)
 
@@ -101,6 +102,16 @@ as intuitive as Dockge, as capable as Portainer for Compose workflows.
 - **Run now** for an on-demand run, plus a `backup_failed` notification event
   wired into the webhook system.
 
+### Phase 8 — Remote-stack backups
+
+- **Back up agent stacks**: the agent exposes its own backup/restore endpoints,
+  and the main app streams a remote stack's backup through to a destination
+  (credentials stay central — agents never see them). Remote stack detail has a
+  **Backup** button; each host section on the Stacks page has a **Restore** button.
+- **Schedule remote stacks**: a backup schedule can target a remote host; backups
+  are namespaced per host (`backup-<host>-<stack>-…`) so retention never prunes
+  across hosts sharing a destination.
+
 ## Deploying an agent on another host
 
 ```bash
@@ -224,6 +235,7 @@ DELETE /api/agents/{id}/stacks/{sid}               POST /api/agents/{id}/stacks/
 
 agent (on the remote host, Bearer AGENT_TOKEN):
 GET    /agent/ping | /system | /stacks | /stacks/{id} | /stacks/{id}/logs
+GET    /agent/stacks/{id}/backup                   POST /agent/stacks/restore
 POST   /agent/stacks | /stacks/{id}/{action}       PUT/DELETE /agent/stacks/{id}
 ```
 
@@ -245,6 +257,14 @@ PUT    /api/backups/schedules/{id}                 DELETE /api/backups/schedules
 POST   /api/backups/schedules/{id}/run
 ```
 
+### Phase 8 endpoints (remote-stack backups)
+
+```
+GET    /api/agents/{id}/stacks/{sid}/backup        POST /api/agents/{id}/stacks/{sid}/backup/push
+POST   /api/agents/{id}/stacks/restore             POST /api/agents/{id}/stacks/restore-from
+backup schedules accept an optional agent_id to target a remote host.
+```
+
 ## Security notes
 
 - The Docker socket is only ever touched by the backend process; it is never