fix: a media backup or restore cut off by a restart carries on where it stopped

A media backup and a restore's file phase run as chains of 45-minute chunks,
each queuing the next when it ends. A restart killed the chunk in flight, so
nothing queued the next one; the run's row stayed "running", "Back up now"
skipped it as already running, and only the 7-hour stall sweep ended it.

- When the long-maintenance lane starts, it queues the next chunk of every
  media run still running and every restore fetching its files.
- Each chunk writes its token to the run and hands it to the chunk it queues.
  A chunk queued by any other chunk is dropped (a killed chunk's message
  redelivered by acks_late, say), so a resume never doubles the chain; a chunk
  taken over stops at its next file.
- The integration job installs postgresql-client when the CI image lacks it:
  the backup round trip in 375e7e2 runs the real pg_dump and pg_restore.

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

README.md

@@ -189,7 +189,8 @@ screen: any S3 bucket (Fabled Archives, MinIO, AWS) and a key that may add and
 read objects. Each night FabledCurator then sends the database as a dated dump
 under `database/`, and every image and attachment once, named by its
 fingerprint, under `media/`. It never deletes from the bucket; the bucket's own
-retention thins old dumps.
+retention thins old dumps. The first copy of a large library takes hours; a
+restart along the way carries on where it stopped rather than starting over.
 
 To rebuild after losing the server, start a fresh install (first boot as
 above), enter the same destination, and under **Restore from the bucket** choose