restore_backup applies an engine-only (exclude_blobs) backup over live blob roots with only a log warning #2640

Pre-existing hazard in restore_backup; a prerequisite for every in-place restore route in #2632 (item 9; design note §7.6 in docs/proposals/archive-restore.md on branch design/archive-restore). Belongs to #2100.

Problem

restoreBlobSnapshot leaves the live blob roots untouched and logs a warning when a backup has no blob snapshot (dataLayer/blobBackup.ts:349-357). That was deliberate — purging would strip blobs the restored records reference — but an in-place restore of an exclude_blobs backup over a database that has blobs produces a mixed generation: rolled-back records against current blob roots. The everyday result is a dangling reference (a blob deleted since the backup point). The worse one is id reuse: file ids are a per-database counter re-seeded from a directory scan at process start (resources/blob.ts:2685), so after deletions of the highest ids plus a restart an old id can be reissued and a restored record then resolves to unrelated bytes.

Today the operator gets a log line and a "successful" restore.

Fix — one rule for managed and imported backups

An in-place restore of a blobs: false backup over a database whose blob roots are non-empty is refused unless the caller opts in explicitly (allow_engine_only: true, recorded in the job). target_database is always allowed (a new name has no pre-existing blobs to disagree with). Apply the same rule in the operation and in the offline CLI; imported engine-only archives inherit it through their manifest.

Acceptance

• In-place restore_backup of an exclude_blobs backup over a database with blobs returns a descriptive error naming the flag; with allow_engine_only=true it proceeds and the job records the opt-in.
• Over a database with empty blob roots, and with target_database, it proceeds without the flag.
• Offline CLI behaves identically.