fix(reorder): trap layer-list drag drop as a data change and persist it

List_PreviewMouseMove reorders StagedScene.Elements via RemoveAt/Insert,
bypassing SceneGraph's mutation surface, but never scheduled a save — the
new z-order was lost on restart. The drop now sets _dragReordered and
EndListDrag funnels it through MainViewModel.OnSceneElementsReordered()
(InvalidateBake + ScheduleSave, same background-save path as every other
mutation). Integration test (RealApp + temp DB) reproduces the exact
code-behind mutation and asserts the debounced save lands the new Source
SortOrder. Derivation reference: standard WPF ItemsControl drag-reorder
pattern (OBS layering semantics: bottom-most layer = index 0).

ViewModels/MainViewModel.Sources.cs

@@ -85,6 +85,15 @@ public partial class MainViewModel
         UpdateActiveBackground();
     }
 
+    /// <summary>Drag-to-reorder in the layer list mutates <see cref="Scene.Elements"/>
+    /// directly in code-behind, bypassing SceneGraph's mutation surface. Trap it here
+    /// so the new z-order persists like any other layout change.</summary>
+    public void OnSceneElementsReordered()
+    {
+        if (StagedScene != null) _sceneGraph.InvalidateBake(StagedScene);
+        ScheduleSave();
+    }
+
     // Duplicate resource names get an incrementing suffix with no space: Image,
     // Image2, Image3… The next free number is derived from the names actually in
     // the scene, so deleting a middle resource never collides with a survivor.