feat(core): perceptual hashes for finding similar photos

A 64-bit difference hash of each thumbnail, stored in the new
photos.similar_hash column (schema 34), and the queries the similar-photo
finder needs: what is left to hash, progress, and the sets of shots that
look alike. Sets made only of byte-identical copies are left to the
duplicate finder. A refresh keeps a hash unless the photo's bytes changed.

The daemon pass, the control request and the GUI are not built yet; see
PLAN.md.

crates/pdfs-core/src/db/migrations.rs

@@ -9,7 +9,7 @@ use super::Db;
 use crate::Result;
 
 /// Current schema version. Bump on every forward migration added below.
-pub(super) const SCHEMA_VERSION: i64 = 33;
+pub(super) const SCHEMA_VERSION: i64 = 34;
 
 impl Db {
     pub(super) fn migrate(&self) -> Result<()> {
@@ -300,6 +300,22 @@ impl Db {
                 tx.execute_batch(MIGRATION_V33)?;
             }
         }
+        if current < 34 {
+            // Same guards as V26-V33.
+            let has_column: bool = tx.query_row(
+                "SELECT COUNT(*) FROM pragma_table_info('photos') WHERE name = 'similar_hash'",
+                [],
+                |row| row.get::<_, i64>(0),
+            )? > 0;
+            let has_photos: bool = tx.query_row(
+                "SELECT COUNT(*) FROM sqlite_master WHERE type = 'table' AND name = 'photos'",
+                [],
+                |row| row.get::<_, i64>(0),
+            )? > 0;
+            if has_photos && !has_column {
+                tx.execute_batch(MIGRATION_V34)?;
+            }
+        }
         tx.execute(
             "INSERT INTO sync_state (key, value) VALUES ('schema_version', ?1)
              ON CONFLICT(key) DO UPDATE SET value = excluded.value",
@@ -1006,3 +1022,14 @@ ALTER TABLE photos ADD COLUMN place_id INTEGER;
 CREATE INDEX IF NOT EXISTS idx_photos_place ON photos(place_id);
 UPDATE photos SET resolved_at = NULL;
 ";
+
+/// Schema v34: what each photo looks like, for finding similar ones.
+///
+/// `similar_hash` is a 64-bit difference hash of the photo's thumbnail (see
+/// `crate::similar`): resized and re-encoded copies of one picture land a few
+/// bits apart, where the server's `content_hash` only matches byte-identical
+/// files. `NULL` until the daemon has hashed the thumbnail, which it does as
+/// thumbnails arrive and when the similar-photo finder asks for the rest.
+const MIGRATION_V34: &str = "
+ALTER TABLE photos ADD COLUMN similar_hash INTEGER;
+";