Fold people of one name whose faces agree, and faces held twice (#78)

Seven names are two or three live people on both devices: Ian (756
confirmed faces, and a second Ian with none), Jessie three times,
Claudine, Mathias, Noemi, Pascal and PJ. Each was typed on its own
device and carried across by sync, which keys people on their uuid and
so keeps both. Each half of a person shows half their photographs.

dedup_people::run, in one transaction:

- Same-name people (trimmed, case-folded as the Identity screen folds
  them) merge into the one with the most confirmed faces, ties to the
  smaller uuid, through faces::merge_people_within, so confirmations,
  rejections and the survivor's name are kept. A person holding no
  faces at all merges: there is nothing to compare or to carry. Anyone
  else needs >= 2 confirmed faces per shared embedder on both sides and
  centroids at cosine >= 0.7 in each. A face confirmed as one and
  rejected as the other keeps them apart. Unnamed and set-aside people
  are never merged by name.
- Faces held twice (one image, one embedder, IoU >= 0.5, cosine >= 0.7)
  keep the stronger detector's row (FaceDetector::outranks), then the
  confirmed one, then the older. The survivor takes the confirmed
  assignment and both rows' rejections. A pair confirmed as two
  different people is left and counted.
- Judgements still on a merged-away person move to the person at the
  end of its redirects, and a redirect cycle (two devices merging one
  pair in opposite directions) is broken at the smaller uuid.

Measured on copies of the desktop catalog and the tablet's server
snapshot, w600k_mbf, confirmed faces only:
- Centroids of differently named people: 2,699 pairs, median 0.02,
  99.9th percentile 0.41. One pair reaches 0.70 (0.700 desktop, 0.705
  tablet), "Michelle Casanonve" and "Michelle Casanova", one person
  typed two ways. Next is 0.62/0.64, "Boris Jost" and "Boris". The
  highest pair that is plainly two people is 0.43/0.44.
- One person split in random halves: minimum 0.69, median 0.91 over 72
  people. Four faces against twenty-two reach 0.7 in 97% of draws.
  One face against twenty of somebody else's reached 0.74 in 3,000
  draws, and two faces reached 0.61, hence the two-face minimum.
- Pascal (22 and 4 confirmed) is at 0.57 and PJ (14 and 7) at 0.50,
  under 0.7 on both devices, so both pairs stay apart and are logged.
  The desktop's second Ian holds 4 suggestions and no confirmations,
  at 0.38 against Ian's centroid, and stays apart. On the tablet it
  holds nothing and merges.

Why a merge made here survives a peer on 0.17.0: the merged-away
person stays as a merged_into redirect with a bumped revision, which
the catalog merge has always taken on revision. The peer hides the
duplicate and never sends it back as a live person. Its own
confirmations of that person stay on the redirect, because a merge
never overwrites a local confirmation. The manual merge has always
left them there too. They follow the redirect when the peer runs this
job. A test syncs two catalog files through the previous merge code
and back, and the people converge and stay converged.

Once a catalog is clean the job reads 80 redirects, the named people,
and the face boxes from the covering faces_box index. That is ~10 ms
on the reference library. There is no schema change. The index is
created IF NOT EXISTS, as the merge already does.

core/dr-catalog/src/faces.rs

@@ -1064,6 +1064,28 @@ pub(crate) fn merge_people_within(
     if target == source {
         return Ok(0);
     }
+    let moved = move_judgements(tx, target, source)?;
+    tx.execute(
+        "UPDATE people SET merged_into = ?1, revision = revision + 1, modified = ?3
+          WHERE id = ?2",
+        rusqlite::params![target.0 as i64, source.0 as i64, now_secs()],
+    )?;
+    Ok(moved)
+}
+
+/// The half of [`merge_people_within`] that moves faces and rejections,
+/// without touching either person's row.
+///
+/// Also what follows a redirect that arrived by sync
+/// (`crate::dedup_people`): the other device merged the people, and this
+/// one still holds judgements on the person merged away. Bumping the
+/// person's revision there would be an edit of this device's own, sent back
+/// on every pass, so the row is left as the merge wrote it.
+pub(crate) fn move_judgements(
+    tx: &Connection,
+    target: PersonId,
+    source: PersonId,
+) -> Result<u64, CatalogError> {
     let (t, s) = (target.0 as i64, source.0 as i64);
     // A face already assigned to the target must not gain a second row —
     // `face_person` is keyed by face. Where both hold the same face, the
@@ -1097,11 +1119,6 @@ pub(crate) fn merge_people_within(
             AND face_id IN (SELECT face_id FROM face_person_rejected WHERE person_id = ?1)",
         [t],
     )?;
-    tx.execute(
-        "UPDATE people SET merged_into = ?1, revision = revision + 1, modified = ?3
-          WHERE id = ?2",
-        rusqlite::params![t, s, now_secs()],
-    )?;
     Ok(moved as u64)
 }
 

core/dr-catalog/src/lib.rs

@@ -42,6 +42,7 @@ pub mod bursts;
 pub mod cache;
 pub mod collections;
 pub mod dedup;
+pub mod dedup_people;
 pub mod duplicates;
 pub mod error;
 pub mod face_shard;

core/dr-catalog/src/merge.rs

@@ -1572,7 +1572,7 @@ fn pair_by_embedding(
 /// extra index is invisible to them. The first merge after an upgrade pays
 /// for building it, once. A failure is logged and the merge goes on reading
 /// rows, as it did before.
-fn ensure_face_box_index(tx: &Connection) {
+pub(crate) fn ensure_face_box_index(tx: &Connection) {
     if let Err(e) = tx.execute_batch(
         "CREATE INDEX IF NOT EXISTS main.faces_box ON faces(image_id, model_id, x, y, w, h);",
     ) {
@@ -1581,7 +1581,7 @@ fn ensure_face_box_index(tx: &Connection) {
 }
 
 /// Intersection over union of two `(x, y, w, h)` boxes.
-fn iou(a: (f32, f32, f32, f32), b: (f32, f32, f32, f32)) -> f32 {
+pub(crate) fn iou(a: (f32, f32, f32, f32), b: (f32, f32, f32, f32)) -> f32 {
     let x0 = a.0.max(b.0);
     let y0 = a.1.max(b.1);
     let x1 = (a.0 + a.2).min(b.0 + b.2);