Record a restore of the channel's database and answer 202.

The checks run in one transaction with the record, in this order, and each refusal records nothing:

1. The channel: 404 for a caller who is not a member.
2. A move that carries the app: 409 maintenance. The check runs under the owner lock in its weaker mode (pg_placement.py::lock_owner_no_key), which conflicts with the FOR UPDATE every plan_apply producer takes before it checks for a restore, so a restore and a plan change of one user never both pass.
3. The prod channel: 403 protected_action unless a person drives the caller or the owner turned agent access on.
4. The typed name: 400 invalid_confirmation.
5. A maintenance_channel_id with a mode other than maintenance: 400 maintenance_channel_needs_maintenance.
6. Degraded mode: 503 postgres_unavailable.

A request_id the ledger already holds then goes straight to the core's verb, which replays the recorded restore, or answers 409 request_id_conflict for an id recorded for another call. A new request takes the channel's row lock (channels/service.py::lock_channel), which the tenant deploy and rewind, the admin rebuild, the operator redeploy, the push worker, and the transfer accept take before they read the restore holds, and meets:

7. The owner, read again under the channel lock: 409 when an ownership transfer changed it since the read of check 1.
8. The snapshot: 404 snapshot_not_found or snapshot_host_gone, and 409 snapshot_out_of_window.
9. The page channel, when the body names one (proxy/maintenance.py::maintenance_target_refusal): 400 maintenance_channel_not_found for a channel that does not exist or has another owner, maintenance_channel_not_static, or maintenance_channel_not_deployed.
10. The core's verb (postgres/api.py::restore_channel_database): 409 when the database is not ready, and 409 restore_in_flight while another restore of the channel is active.

Once the core records the restore, the same transaction cancels the channel's queued deploys and rewinds (deploy/dispatch.py::cancel_queued_for_restore). A running deploy and a queued rehome are left alone: the restore waits for them (design/PG-FLEET.md, "Guards while a restore is active").

The body's during_restore, read_only by default, maintenance, or live, and its maintenance_channel_id are parameters of the recorded command, so a replay that names another mode or another page channel answers request_id_conflict. The answer is the restore's status and the ids of the deploys its start cancelled, with Location naming its status route. A replay reads the cancelled deploys back and cancels nothing. The route then nudges the restore dispatcher.