Record in the catalog design how duplicate originals are proved

catalog.md said content_hash is computed only for import duplicate
detection and reconnection, and left "the same image catalogued twice"
as unspecified. FR-CAT-11a now handles the within-root case: it proves a
group by content_hash where every copy has one, otherwise by first and
last megabyte digests kept in dedup_probes, a table created on first use
rather than by migration (core/dr-catalog/src/duplicates.rs:296). The
cross-root case stays open, and the bullet now says which half is done.

docs/dev/catalog.md

@@ -249,6 +249,13 @@ what you actually have.
 only when something needs it: import duplicate detection (FR-CAT-11), or reconnecting a moved source
 (FR-CAT-9). Never during a routine scan.
 
+Consolidating the duplicates a library already holds (FR-CAT-11a, 0.16.0) does not wait for it. It
+proves a group the same by `content_hash` where every copy has one, and otherwise by a digest of
+each copy's first and last megabyte, read by range through the backend and kept in `dedup_probes`
+keyed on the size and mtime it was taken at, so a second review reads nothing.
+`dedup_probes` is created on first use rather than by a migration, because a schema bump would make
+an older build refuse this catalog's snapshot at sync (`core/dr-catalog/src/duplicates.rs`).
+
 ---
 
 ## 4. The library view
@@ -711,8 +718,9 @@ because if the SQLite path proves troublesome, this is the fallback with a known
   membership needs to be *stable* — for manual ordering, or for a pinned set that must not shift
   under the user — it needs materialising with an invalidation rule. Deferred until there is a
   concrete need.
-- **Multi-root capture-time collisions.** FR-CAT-11 detects duplicates on import; the same image
-  catalogued under two roots is a related but distinct case, not yet specified.
+- **Multi-root capture-time collisions.** FR-CAT-11 detects duplicates on import, and FR-CAT-11a
+  consolidates the copies one root holds in several folders; the same image catalogued under two
+  roots is a related but distinct case, not yet specified.
 - **Timeline granularity selection.** Which bucket size the UI picks for a given zoom is a UI
   concern, but the catalog should probably suggest one from the query's date span rather than have
   the UI guess.