Back up several stacks, or all of them, from one schedule (0.65.0)

A schedule covered exactly one stack, so backing up a host meant one
schedule per stack, each edited separately, and new stacks were only
backed up once someone remembered to add a schedule.

A schedule now takes a list of stacks, or all_stacks, which includes
stacks added later. They are backed up one after another, each with its
own file, upload, retention and status, so one failing stack does not
cost the others their backup:

- stack_status records each stack's result; last_status summarises
  ("error: 2 of 5 stacks - a: ...; c: ...") and one notification per run
  names the stacks with a problem. The dashboard names them too and shows
  an incomplete backup as a warning rather than an error.
- A busy stack (deploy, update) is retried after the others, up to three
  times two minutes apart, replacing the 10-minute postponement of the
  whole schedule.
- Run now starts the run in the background (202) instead of holding the
  request, which a multi-stack run would outlast; the list reports
  running and polls, and the row toasts the outcome. A schedule never
  runs twice at once.
- Settings: "All stacks" or a checklist with select all/none; stacks can
  be changed when editing; deleted stacks stay listed to be unticked.

Schedules from before keep working without a data migration: stack_ids,
all_stacks and stack_status are added with defaults on startup and a row
with only stack_id reads as that one stack. The API still accepts
stack_id and reports it for single-stack schedules.

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

README.md

@@ -643,13 +643,20 @@ it is what your saved destination credentials are encrypted with.
 
 ### Phase 7 — Scheduled backups
 
-- **Recurring backups**: schedule a stack to back up to a destination **hourly,
+- **Recurring backups**: schedule stacks to back up to a destination **hourly,
   daily, or weekly** (UTC) under **Settings → Scheduled backups**. A background
   scheduler runs due jobs every minute and records last/next run + status.
+- **Several stacks per schedule** (0.65.0): tick any number of stacks, or
+  *All stacks* to include stacks added later without editing the schedule. They
+  are backed up one after another, each to its own file with its own retention
+  and status, so one failing stack does not cost the others their backup; the
+  schedule lists which stack had a problem. A stack that is busy (deploying,
+  updating) is retried after the others. Schedules from before keep working.
 - **Retention**: keep the newest *N* backups per stack on the destination; older
   ones are pruned automatically.
-- **Run now** for an on-demand run, plus a `backup_failed` notification event
-  wired into the webhook system.
+- **Run now** for an on-demand run (in the background; the row shows it running
+  and then the result), plus a `backup_failed` notification event wired into
+  the webhook system.
 
 ### Phase 9 — Networks
 
@@ -1090,7 +1097,8 @@ POST   /api/stacks/{id}/backup/push                POST /api/stacks/restore-from
 ```
 GET    /api/backups/schedules                     POST /api/backups/schedules
 PUT    /api/backups/schedules/{id}                 DELETE /api/backups/schedules/{id}
-POST   /api/backups/schedules/{id}/run
+POST   /api/backups/schedules/{id}/run            (202, runs in the background)
+       body: {"stack_ids": [...] | "all_stacks": true, "destination_id": …, …}
 ```
 
 ### Phase 9 endpoints