Let a manual collection be put in the order the photographer wants

`collections::set_order` and `Sort::CollectionPosition` have been in the
catalog since collections were, and nothing above dr-catalog has ever
called either. A manual order existed, could not be seen, and could not be
set. This is the half that was missing.

Three pieces, because it needed all three to be visible at all.

The catalog gains `orders_manually` and `members_in_order`. The first is
the rule about *when* a manual order means anything, kept in one place with
one name: a collection must be manual, and it must have no children. A set
shows its descendants' images, and positions are only ever assigned within
one collection — so two children's positions are unrelated integers, and
ordering by them would sort the grid by a coincidence. The existing comment
on `read_cells_scoped` already argued this; now something enforces it.

`members_in_order` returns the *whole* membership rather than the filtered
view, because `set_order` renumbers exactly what it is handed. Reordering a
filtered list would renumber those and leave every hidden image on a stale
position — two images sharing one, and a grid that rearranges itself the
moment the filter comes off.

The grid reads position where the scope qualifies and capture time
everywhere else. Manual order joins the member row rather than testing
membership with `IN`, which is safe from fanning out rows *because* that
branch is a single collection.

The gesture is a DropArea over the viewport, drawn only where a reorder
means something, with a caret in the gap the photographs would go into —
a line between two images rather than a highlight on one, because lighting
up a cell would say the drop replaces it.

The trap worth naming: `DropEvent.position` is in **window** coordinates.
Slint maps it through `map_to_window` when the drag begins and hands every
target the same event untranslated, so a target inside a Flickable has to
subtract its own `absolute-position`. Getting that wrong is invisible until
the grid is scrolled, because at the top the two frames coincide.

`reordered` is pure and names its destination by the image it goes before
rather than by an index, because the grid can only name a gap in what it is
showing and the ids are what survive a window swap. A drop that changes
nothing returns the order untouched: that counter is what a cross-device
merge resolves by, and spending a revision on a no-op makes this device win
an argument it did not have.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

ui/dr-ui/src/library_ui.rs

@@ -2114,6 +2114,23 @@ fn load_window(window: &AppWindow, ctl: &Rc<LibraryController>) {
         refresh_timeline(window, catalog, ctl);
     }
 
+    // TRACES: FR-CAT-7
+    // Whether this scope has an order a drag can change, which is what lets the
+    // grid draw an insertion caret and accept a drop.
+    //
+    // Answered here because this is the one place that runs on every re-read —
+    // a scope change, a reorder, a collection gaining a child that turns it
+    // into a set — so the caret cannot outlive the scope that justified it.
+    //
+    // The trash is never reorderable. It is a view of what was deleted, ordered
+    // by when, and it is not a collection at all.
+    window.set_library_manual_order(
+        !trash
+            && scope.is_some_and(|c| {
+                dr_catalog::collections::orders_manually(catalog.connection(), c).unwrap_or(false)
+            }),
+    );
+
     let cells = if trash {
         library::read_trashed_cells(catalog, offset, window_size)
     } else {