feat(6848): Settings restore rolls back, from the destination or a file, after a preview

The web restore no longer copies a backup in beside the live data.

- GET /api/admin/restore/sources lists the backups at the backup destination,
  newest first.
- POST /api/admin/restore/preview says what a restore would do, changing
  nothing: fresh or rollback, when the backup was taken, and counts now and
  after per kind. A backup that cannot apply here gets a 409 with the reason.
- POST /api/admin/restore?confirm=rollback runs backup_job.rollback_to_backup:
  safety backup, replace, then search rebuilt in the background.

Each takes ?source=<name> (a backup at the destination) or an upload. The
destination path exists because uploads are held to the request-size limit,
and a real instance's backup is far over it. backup_s3.get_file downloads
from a bucket. backup_destination.list_backups/open_backup only accept names
the scheduled backup writes, so a request cannot reach any other file.

Settings -> Data -> Restore from Backup opens RestoreBackupDialog. The dialog:
1. Pick a backup at the destination or a file.
2. Read the preview.
3. Type "roll back".
4. Run it. The dialog then says where the replaced state was saved, and sends
   the user to sign in again.

Closes #6840. Milestone 582, step 4.

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

src/grimoire/services/backup_s3.py

@@ -4,9 +4,10 @@ path-style addressing (endpoint/bucket/key), and the two calls a backup needs.
 The signing is checked against AWS's published SigV4 examples in
 tests/test_services_backup_s3.py.
 
-Grimoire puts and lists; it never deletes. The bucket keeps the history and
-thins it on its own policy, so a key that may only add objects is enough —
-and is the safer key to hand a service, because a stolen one cannot wipe the
+Grimoire puts and lists, and reads a backup back when an admin restores from
+the bucket; it never deletes. The bucket keeps the history and thins it on
+its own policy, so a key that may only add and read objects is enough — and
+is the safer key to hand a service, because a stolen one cannot wipe the
 history it writes into.
 
 Written by hand rather than with boto3: two calls don't justify a large
@@ -171,6 +172,28 @@ async def put_file(target: S3Target, key: str, path: Path, *,
         raise S3Error(f"Upload of {key} refused: {_says(response)}")
 
 
+async def get_file(target: S3Target, key: str, path: Path, *,
+                   transport: httpx.AsyncBaseTransport | None = None,
+                   now: datetime | None = None) -> None:
+    """Download one object to `path`, streamed to disk."""
+    url = target.url(key)
+    headers = sign("GET", url, {}, EMPTY_SHA256, target.access_key, target.secret_key,
+                   target.region, now or datetime.now(timezone.utc))
+    try:
+        async with httpx.AsyncClient(verify=target.verify_tls,
+                                     timeout=UPLOAD_TIMEOUT_SECONDS,
+                                     transport=transport) as client:
+            async with client.stream("GET", url, headers=headers) as response:
+                if response.status_code != 200:
+                    await response.aread()
+                    raise S3Error(f"Reading {key} refused: {_says(response)}")
+                with open(path, "wb") as f:
+                    async for chunk in response.aiter_bytes(CHUNK):
+                        f.write(chunk)
+    except httpx.HTTPError as exc:
+        raise _reach_error(target, exc) from None
+
+
 async def list_objects(target: S3Target, prefix: str = "", limit: int = 1000, *,
                        transport: httpx.AsyncBaseTransport | None = None,
                        now: datetime | None = None) -> list[StoredObject]: