refactor(consistency): blobs_consistency reads only the database

`blobs_consistency` probed `blob_exists` once per row and, under
`?deep=true`, read and re-hashed every blob. `backend_consistency`
already reports the same `blob_missing_from_backend` from its
merge-join — so the probe was duplicated work that found strictly less
(a DB walk cannot see backend-only orphans by construction) at N round
-trips instead of one enumeration. Every scheduled sweep paid for it.

All three physical checks move to `backend_consistency`:

* `blob_missing_from_backend` was already there; the duplicate is gone.
* `blob_corrupted` / `blob_unreadable` hook the matched arm of the
  merge-join, which holds exactly the key pairs worth reading. Guarded
  by `in_range` so a pair past the horizon is not read twice, and
  `params.deep` is persisted on a fresh run and read back on resume so
  a paused deep scan does not silently continue shallow.

Deep mode belongs there because it is backend work end to end: the
only DB input is the hash. Keeping it in `blobs_consistency` forced
that tenant to carry a backend for one flag.

What remains is the half that needs no backend: `refcount_mismatch`
and its repair. The constructor drops from five parameters to two —
no backend, no storage_entries, no storage_path_fallback — and
`?storage=<name>` / `?deep=true` are now inert there, which the
job description says outright.

`affected_files` is needed by both tenants, so it moves to a shared
`blob_diagnostics` module rather than being copied.
`PROBED_STORAGE_PARAM` moves to `backend_consistency`: it was defined
in `blobs_consistency` and re-exported, which is backwards once the
DB-only tenant has no entry to scope. The create-grace window goes
with the probe — it existed to avoid flagging a blob whose bytes had
landed before its row, and the refcount comparison reads one
consistent snapshot.

Known cost: `backend_consistency` returns `backend_unenumerable` on
Azure and mid-migration, so on those configs missing bytes now go
unreported where the per-row probe caught them. That argues for the
Azure enumeration impl, not for keeping the probe.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

frontend/src/lib/components/AdminJobsPanel.svelte

@@ -637,13 +637,14 @@
 	// Jobs that respect `?deep=true`:
 	//   * `consistency_batch` — propagates deep to every child that
 	//     understands it
-	//   * `blobs_consistency` — deep mode re-reads + re-hashes every
-	//     blob for silent bit-rot detection (severity `data_loss`).
-	//     Full read of storage; can take hours on big installs — the
-	//     "Run" (normal) button on the same row does the cheap
-	//     existence probes only.
+	//   * `backend_consistency` — deep mode re-reads + re-hashes every
+	//     matched blob for silent bit-rot detection (severity
+	//     `data_loss`). Full read of storage; can take hours on big
+	//     installs — the "Run" button on the same row does the
+	//     enumeration merge-join only. This was `blobs_consistency`
+	//     until that tenant became database-only.
 	function supportsDeep(name: string): boolean {
-		return name === 'consistency_batch' || name === 'blobs_consistency';
+		return name === 'consistency_batch' || name === 'backend_consistency';
 	}
 
 	// Whether `?repair=true` does anything for this job — declared by the