feat(gui,fuse): delete photos from the gallery and notice remote deletions

The gallery could show photos and nothing else: a photo deleted on the phone
stayed on the page for minutes, and a photo you wanted gone had to be deleted
on another device. Both are now handled here.

Deleting needs a uid-addressed request, because `Request::Delete` takes a
mountpoint path and the photos volume is not in the FUSE mount. `TrashNodes`
trashes through the SDK and answers per-uid outcomes, so a partial failure is
reportable; the daemon then drops those rows with `Db::photos_delete`, album
membership included, rather than leaving the gallery to wait for the next
timeline refresh. The GUI removes the tiles immediately with an Undo toast and
puts back anything the server refused — the photos are in Proton's trash and
stay recoverable there either way. Selection is Ctrl/Shift+click, the Select
toggle or Delete in the lightbox.

Remote deletions arrive on their own now. The Drive volume and the photos
volume have separate event streams, so the photos volume gets its own poller
and its own cursor. Trash and delete events remove rows; anything else only
marks the timeline stale, because there is no inode space to converge on this
volume. With the timeline TTL down to 60 s and an explicit Refresh that waits
for the server instead of only clearing the freshness stamp, a photo deleted
elsewhere leaves the grid in about ten seconds.

docs/CHANGELOG.md

@@ -14,6 +14,23 @@ scratch (user data in `staging/` and `recovery/` is never touched by this).
 Schema: **29** (`trash.parent_uid`); SDK bumped to `proton-sdk` / `proton-drive-rs` **0.6.5**.
 
 ### Changed
+- **The gallery lays photos out in justified rows.** Every tile is now its own photo's shape:
+  photos are taken in capture order until they no longer fit the target height, and the row is
+  then scaled to land exactly on the right margin. Nothing is cropped and nothing is
+  letterboxed, which is what the square centre-cropped tiles used to do to portraits and
+  panoramas. The last row of a day stays at the target height rather than being stretched, and
+  Ctrl+scroll / Ctrl+± now changes that target height. Gaps and tile corners are smaller, so the
+  page reads as photos rather than as cards.
+- **Thumbnails stay on screen while you scroll.** A decoded thumbnail now lands in the texture
+  cache even when the tile that asked for it has already been recycled, the cache is a real LRU
+  holding 1500 textures instead of 600, and the rows just past the edge of the window are
+  fetched ahead of the scroll direction. Scrolling fast through a large timeline no longer
+  leaves a screen of blank tiles behind.
+- **Refresh on the Photos page really refreshes.** It now waits for the timeline to come back
+  from the server before it answers, instead of only clearing the freshness stamp and letting
+  the next read serve the stale page. The timeline is also considered stale after 60 s rather
+  than 5 minutes.
+
 - **Restore puts back the whole tree.** The trash is a flat list, but you delete a shape: a
   folder, and often things you had already deleted inside it. Restoring a folder now also
   restores the items that were trashed inside it, and restoring one of those items first
@@ -23,6 +40,14 @@ Schema: **29** (`trash.parent_uid`); SDK bumped to `proton-sdk` / `proton-drive-
   not cancel the rest.
 
 ### Added
+- **Delete from the gallery.** Select photos with the Select button, with Ctrl+click or with
+  Shift+click, then Move to Trash — or press Delete in the lightbox. The tiles leave the grid
+  immediately with an Undo toast, and the photos land in Proton's trash, where they stay
+  recoverable. A photo the server refuses to trash comes back into the grid.
+- **A photo deleted on your phone disappears here.** The daemon now follows the photos volume's
+  own event stream, so a photo trashed on another device leaves the gallery within about ten
+  seconds instead of waiting for the timeline to go stale.
+
 - **`pdfs diagnostics`.** Reports what the daemon is doing right now: every worker thread with the job
   it holds and for how long, queue depths per lane, the control requests still in flight, resident
   size and the pending-op count. Answers even while the daemon is wedged, which is the only time

docs/DEVELOPMENT.md

@@ -142,6 +142,16 @@ The gallery can mark and filter favourites, through the SDK's photo-tag API (`up
 
 Favouriting a photo that is not on this account's own photos volume (shared with us, or album-only) needs it re-encrypted for our timeline root, which the SDK does not implement; the daemon surfaces that as an error rather than silently doing nothing.
 
+### Justified Gallery, Gallery Delete (Implemented)
+**Files**: [`photos.rs`](../crates/pdfs-gui/src/app/pages/photos.rs), [`photo_viewer.rs`](../crates/pdfs-gui/src/app/pages/photo_viewer.rs), [`photos.rs`](../crates/pdfs-fuse/src/photos.rs), [`background.rs`](../crates/pdfs-fuse/src/background.rs)
+
+The gallery lays each day out in justified rows (`justify_rows` / `plan_rows` / `fit_row`): photos are taken in capture order until their summed aspect ratio no longer fits the target row height, and the row is then scaled so it ends exactly on the content width. A tile is therefore its own photo's shape, and `ContentFit::Contain` has nothing left to crop. The last row of a day is left at the target height rather than stretched, because a day holding two photos is a short day, not a layout fault.
+
+- **Ratios that are not known yet.** `PhotoItem::ratio` is persisted, but a photo that has never been decoded has none. Those are laid out square and remembered in `assumed_ratios`; when a decode proves the real shape the day re-flows on the existing debounce timer, so a screenful of decodes costs one re-flow rather than one per photo. Ratios are clamped to 0.4–3.0 so a single panorama cannot decide what a row looks like.
+- **Thumbnails survive recycling.** A reply for a tile that has already been re-bound still lands in the texture cache, which is an LRU of 1500 textures keyed by uid, and the rows just outside the realised range are prefetched in the scroll direction.
+- **Delete is uid-addressed.** The photos volume is not in the FUSE mount, so the path-based `Request::Delete` cannot reach it. `Request::TrashNodes { uids }` trashes through the SDK and answers `Response::Trashed { trashed, failed }`; the daemon then drops those rows with `Db::photos_delete` (album membership included) so the gallery does not wait for a timeline refresh. The GUI removes the tiles optimistically with an Undo toast and puts back anything the server refused.
+- **Remote deletions arrive on their own.** The Drive volume and the photos volume have separate event streams, so `run_photos_event_sync` polls the photos volume with its own cursor (`photos_event_cursor` in the state table). Trash and delete events remove rows; anything else only invalidates freshness, because there is no inode space to converge on this volume. Together with a 60 s `TIMELINE_TTL` and a `RefreshScope::Photos` that now awaits the refresh, a photo deleted on a phone leaves the grid in about ten seconds.
+
 ### Persistent SDK Entity Cache (Implemented)
 **Files**: [`sdkcache.rs`](../crates/pdfs-core/src/sdkcache.rs), [`auth.rs`](../crates/pdfs-core/src/auth.rs), [`background.rs`](../crates/pdfs-fuse/src/background.rs)