v1.1.24 — Restore jobs + backup agent auto-resync

Restore jobs (new)

• New customer-facing restore path: POST /s3/backup-jobs/{id}/restore dispatches a restore_snapshot command to the owning agent, restoring backup data to an explicit destination_path (optionally scoped to restore_paths) and mandatorily checksum-verifying the result before it's ever reported completed.
• New s3_restore_jobs table/model/service/filter/transformer + read-only GET /s3/restore-jobs, GET /s3/restore-jobs/{id} endpoints — same read-only pattern as backup-job-runs.
• s3_backup_jobs gains an engine column (rsync default, kopia opt-in), immutable after creation. rsync jobs always restore current bucket state; kopia jobs restore a specific point-in-time snapshot via s3_backup_job_run_id. Enforced in RestoreJobsService::startRestore().

Backup agent: auto-recover from a stale job list

• BackupAgentEventService::handleResult() now re-sends full_sync whenever an agent replies status: rejected to a command — this generally means the agent's local job list is stale relative to the platform (reconnected before the last full_sync landed, or a job changed after its last sync).
• For run_job_now specifically, a rejection also triggers an automatic retry of the run after the resync (BackupAgentCommandService::retryRunJobNowAfterRejection()), capped at 3 consecutive rejections. Past that, the platform stops looping and leaves a system comment on the job (via CommentsService::createSystemComment()) for manual follow-up instead of retrying forever.

Full protocol/schema details: docs/backup.agent/protocol.md, docs/backup.agent/database.md, docs/backup.agent/updates/2026-07-06-restore-jobs.md.