Keep both devices' keywords when the catalogs meet

Keywords are catalog state, and the catalog syncs. Without this, two devices
keywording the same library would resolve to whichever synced last, and an
afternoon of work would vanish with no sign it had ever happened.

The vocabulary merges per row on the rule collections already use: revision
first, timestamp only to break a tie, so a device with a skewed clock cannot win
by having the wrong idea of the time. Assignments merge as a set union, which is
FR-NC-9's principle applied to metadata instead of edit nodes — disjoint work
survives on both sides.

Three things needed care and are commented where they happen:

A deletion travels *by name*, not by identity. Both devices may have minted
their own uuid for one word before they ever synced, so deleting by uuid would
tombstone a row nothing was assigned to and leave every photograph still
carrying the word. The union then refuses to readmit a word a winning tombstone
has just removed — without that filter the remote's live assignments would
resurrect it on the very same pass.

Images are resolved by the server's file id first and the content hash second.
Membership has always used the hash alone, but the hash is computed only when
import dedup or a reconnect asks for it, which for most libraries is never — so
a hash-only union would have quietly done nothing for the ordinary photograph.

A word lands on the local default version. Version uuids do not reconcile in the
catalog at all: ensure_default_versions mints a fresh one per device, so a
uuid-keyed join would have unioned nothing.

Removal still does not propagate. That is the trade collection membership
already makes, for the same reason — an unwanted keyword is removed again in a
second, and a silently lost afternoon is not recoverable at all.

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

core/dr-catalog/src/sync.rs

@@ -16,10 +16,11 @@
 //!
 //! # What is actually synced
 //!
-//! Only collections merge (see [`crate::merge`]). The rest of the catalog is a
-//! *local index* of *local* storage — folder mtimes, cache paths, job rows —
-//! and copying another device's version of those in would be actively wrong.
-//! The remote file is read for its collections and then discarded.
+//! Only the *user's judgements about their library* merge: collections, and the
+//! keyword vocabulary with its assignments (see [`crate::merge`]). The rest of
+//! the catalog is a *local index* of *local* storage — folder mtimes, cache
+//! paths, job rows — and copying another device's version of those in would be
+//! actively wrong. The remote file is read for those two and then discarded.
 //!
 //! This is why the catalog remains disposable in the ARCH §6.12 sense: nothing
 //! here makes the local database authoritative for anything a rebuild could
@@ -96,7 +97,7 @@ pub fn merge_remote(conn: &Connection, remote: &Path) -> Result<MergeReport, Cat
         [remote.to_string_lossy().as_ref()],
     )?;
 
-    let result = merge::merge_collections(conn);
+    let result = merge::merge_all(conn);
 
     // Detach even if the merge failed, or the next attempt errors with
     // "database remote_cat is already in use".