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

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.