Show live progress while pruning volumes, and ask first (0.62.0)

The volume prune gets the same treatment as the image prune in 0.61.0:
the candidates are listed and removed one by one in the background, and
the Volumes page shows a progress bar (x / y, the volume being removed,
failures) followed by a toast with the space freed.

The button also used to delete without asking, and a bare docker volume
prune only removes anonymous volumes on Engine 23+ with no way to include
named ones. It now opens a confirmation dialog with an explicit -a option
that warns it also takes the data of every stack that is down.

- Candidates: volumes no container (running or stopped) mounts, local
  scope only, and anonymous (com.docker.volume.anonymous) unless -a.
  Volumes from pre-23 daemons carry no such label, so they only go with
  -a, which errs on the side of keeping data.
- Removed without force, so a volume mounted since the listing is
  refused; one refusal does not stop the rest.
- No closing daemon prune: nothing is left over, and on a pre-23 daemon an
  unfiltered one would delete named volumes too.
- Freed space is the sum of the deleted volumes' sizes (volumes share no
  data), from the size cache, which is invalidated afterwards.
- POST /api/volumes/prune takes all= and background=; without background
  it still waits and returns {VolumesDeleted, SpaceReclaimed}.
  GET /api/volumes/prune-status is admin-only.
- volume_sizes() ("Compute sizes") now uses the long-timeout client; it
  walks every volume and could hit the same 60s limit.

The progress machinery moved into services/prune_job.py (PruneJob,
PrunePlan) and, on the frontend, the usePruneJob hook and PruneProgress
component, shared by both pages. The status now carries a phase
(preparing / removing / finishing) so the parts without a count say what
they are doing.

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

README.md

@@ -804,7 +804,12 @@ GET  /api/images/prune-status              (progress of the running / last prune
   still labelled with a stack that has been deleted form their own group, marked
   *stack removed* — that is where forgotten data collects.
 - Admin actions: delete a volume (with an in-use warning + force option) and
-  **Prune unused**; an *Only unused* filter.
+  **Prune unused**; an *Only unused* filter. The prune asks first and removes
+  only unused **anonymous** volumes unless *Also remove unused named volumes
+  (`-a`)* is ticked, which also takes the data of every stack that is down. It
+  runs in the background with the same **live progress** as the image prune and
+  reports the space freed (`POST /api/volumes/prune?all=…&background=true`,
+  `GET /api/volumes/prune-status`).
 - **Volume sizes** are loaded on demand via a *Compute sizes* button (runs
   `docker system df`, which walks volume contents and can take a few seconds);
   results are cached ~60s. Endpoint `GET /api/volumes/sizes`.
@@ -1010,7 +1015,8 @@ WS     /ws/deploy/{stack_id}                     WS  /ws/update/{stack_id}
 
 ```
 GET    /api/volumes | /orphaned                  DELETE /api/volumes/{name}
-POST   /api/volumes/prune                        POST /api/volumes/generate-yaml
+POST   /api/volumes/prune?all=&background=     POST /api/volumes/generate-yaml
+GET    /api/volumes/prune-status
 GET    /api/host/paths?path=&show_hidden=        (sandboxed browser)
 POST   /api/editor/services | add-volume | set-gpu | add-device | remove-device | set-privileged
 ```