feat(core,fuse): group the RAW and the JPEG of one shot

A camera that writes both puts two files on the volume, and the timeline showed
two tiles of the same photo. They are one shot to the person who took it.

Schema v30 records what ties them together: the server's own duplicate hash and
main-photo relation, plus a `group_key` every member of a shot carries. The key
is computed when the timeline is replaced, in three steps — the server relation
first, because it knows about live photos and bursts and we do not have to guess
at them; then same capture day, same file-name stem and one member raw while the
other is not, which is the pair a camera writes; otherwise the photo is its own
group. The member the grid shows is the non-raw one, since a JPEG decodes in
milliseconds and is what the person expects to see.

The gallery therefore pages by group and carries `group_size` and `has_raw` on
each entry, and the date scrubber counts what the page shows. The Raw tab is the
exception and still lists every raw file, because that tab exists to answer
"which raws do I have". Album pages are not grouped at all: an album is a list
someone made, and it shows exactly what they put in it.

`TimelineRow` is a struct now. It had grown to five positional fields and was
about to grow to seven, at which point nobody can read a call site.

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 = 29;
+pub(super) const SCHEMA_VERSION: i64 = 30;
 
 impl Db {
     pub(super) fn migrate(&self) -> Result<()> {
@@ -236,6 +236,24 @@ impl Db {
                 tx.execute_batch(MIGRATION_V29)?;
             }
         }
+        if current < 30 {
+            // Same guards as V26-V29: the column may already be there on a
+            // fixture rewound from the current schema, and a very old fixture
+            // may not have `photos` at all.
+            let has_column: bool = tx.query_row(
+                "SELECT COUNT(*) FROM pragma_table_info('photos') WHERE name = 'group_key'",
+                [],
+                |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_V30)?;
+            }
+        }
         tx.execute(
             "INSERT INTO sync_state (key, value) VALUES ('schema_version', ?1)
              ON CONFLICT(key) DO UPDATE SET value = excluded.value",
@@ -881,3 +899,22 @@ const MIGRATION_V29: &str = "
 ALTER TABLE trash ADD COLUMN parent_uid TEXT;
 CREATE INDEX IF NOT EXISTS idx_trash_parent ON trash(parent_uid);
 ";
+
+/// Schema v30: a RAW and the JPEG of the same shot are one photo to the person
+/// who took it, so the timeline records what ties them together.
+///
+/// `content_hash` and `main_uid` come from the server's own photo properties —
+/// the duplicate-detection hash, and the main photo a related one belongs to.
+/// `group_key` is what the gallery pages by: every member of one shot carries
+/// the same key, and the member the grid shows is the one whose `main_uid` is
+/// its own uid.
+///
+/// All three are `NULL` until the next timeline refresh resolves the photo's
+/// node, and a row without a `group_key` is its own group — which is exactly how
+/// the gallery behaved before this column existed.
+const MIGRATION_V30: &str = "
+ALTER TABLE photos ADD COLUMN content_hash TEXT;
+ALTER TABLE photos ADD COLUMN main_uid TEXT;
+ALTER TABLE photos ADD COLUMN group_key TEXT;
+CREATE INDEX IF NOT EXISTS idx_photos_group ON photos(group_key);
+";