Merge: origin's sync ordering and adoption work, its scan-complete trigger ported into library_ui/

docs/dev/catalog.md

@@ -530,6 +530,15 @@ Three invariants, each tested:
 | Re-storing an existing id updates in place, never migrates | Migrating would rewrite a sealed shard |
 | Merging another client's shard is insert-only and idempotent | Both copies derive from the same bytes by the same code, so neither is better; preferring ours avoids dirtying a shard others have synced |
 
+**When the exchange runs.** Corrected 2026-09-20. It fired only after the metadata sweep — hours
+on a large library — so a fresh device re-derived every thumbnail it looked at, re-detected faces
+and re-read every header before adopting the shards and snapshot that held all of it. It now also
+fires the moment the scan completes, which is the first moment the rows the merges key on exist,
+and the sweep starts behind it. In steady state that pass is one listing. The catalog merge also
+takes **capture metadata** (`captured_at`, offset, camera, lens, ISO) for images still at
+`metadata_state < 2`, matched by `oc:fileid` — a date is a fact about the file's bytes, not local
+state, and the snapshot already carried it; the sweep's per-chunk query then finds nothing left.
+
 **The transfer**, in `dr-ui`'s `derived_sync`, exchanges shards with `.darkroom-derived/` under the
 library root. `ThumbStore::shards()` reports which are sealed, so an up-to-date client's whole pass
 is one listing plus whichever shard is still open.