feat(admin): say what a queued restore is waiting for

A restore never runs beside a backup pass or another large job: the
heavy lane puts its delivery back in the queue for a minute at a time.
The job's own row says queued for the whole wait, and the console said
the restore starts "as soon as the background worker picks it up",
which read as a stuck worker while a backup ran.

The status routes now ask the queue. A delivery the lane put back sits
in created with a start_after ahead of now, and the active row of a
heavy queue is what holds the lane. The job view carries
waiting: "backup" | "busy" | null, and the console says it waits for
the running backup, or for another large job, and since when it has
been queued, in all nine locales. A queue that cannot be asked answers
no wait and is reported at warn.

The job view and its reads move to backup-restore-view.ts, which keeps
the worker module under its size baseline.

docs/api/openapi.yaml

@@ -89724,6 +89724,17 @@ components:
           anyOf:
             - $ref: "#/components/schemas/AdminBackupRestoreFailure"
             - type: "null"
+        waiting:
+          anyOf:
+            - type: string
+              enum:
+                - backup
+                - busy
+            - type: "null"
+          description: "Why a `queued` job has not started. A restore never runs beside a backup or another large job: while one
+            holds the server it goes back to the queue for a minute at a time. `backup` when a backup pass holds it,
+            `busy` for anything else (an import, a nightly pass, the memory guard). Null while the job only waits for
+            the worker, and on every job that is not queued."
         attempts:
           type: integer
           minimum: -9007199254740991
@@ -89749,6 +89760,7 @@ components:
         - progress
         - result
         - failure
+        - waiting
         - attempts
         - createdAt
         - startedAt