test: prove layer drag-reorder persists via REAL injected mouse input

Creator reported the layer reorder still "doesn't save" after the 08:18
fix (c117885). The existing Good Dog test short-circuited EndListDrag — it
called OnSceneElementsReordered() directly, so the actual
List_PreviewMouseLeftButtonDown/Move/Up handlers were never exercised
(synthetic RaiseEvent can't: e.GetPosition reads the physical cursor).

New RealMouseDrag_OnTheLayerList_PersistsTheReorder drives SetCursorPos +
mouse_event (Win32 input injection, the same technique UI-automation
tooling uses) so the REAL handlers run: click ImgC's row, drag it onto
ImgA's row on screen, release, then pump until the debounced save writes
the DB. Green: DB ends at [Background, ImgC, ImgA, ImgB] — the seam is
proven end-to-end. If the creator still sees a revert, the run binary was
stale (Debug exe 08:42 postdates the fix commit 08:18) or another deploy.

Reference: Win32 SendInput/mouse_event input injection for WPF e2e
(mouse_event docs / UI-automation tooling pattern).

HANDOFF.md

@@ -1,9 +1,10 @@
-# HANDOFF — 2026-09-18 (drag-reorder persistence + recording-dialog height, both local — no push)
+# HANDOFF — 2026-09-18 (drag-reorder persistence proven via real mouse input + recording-dialog height, both local — no push)
 
 ## Branch / Commit State
 
 `main` HEAD = **Rename Recording dialog 20% taller + teardown unhooks the full-screen hook** (local).
 Below it: the layer drag-reorder persistence fix (`LayerReorderPersistenceTests`), then webcam work.
+**Real-input drag verification test added on top** (unpushed, see below).
 
 **No push yet.** Working tree clean.
 
@@ -63,6 +64,15 @@ ScheduleSave()`, i.e. the same background-save path every other mutation uses. *
 `LayerReorderPersistenceTests` (real App + temp DB): reproduces the exact code-behind mutation,
 calls the trap, pumps the dispatcher until the debounced save lands, asserts the DB `Source`
 SortOrder matches the in-memory `Elements` order.
+**Creator later insisted the reorder "doesn't save" even after the build — settled 2026-09-18 with a
+REAL-gesture test.** My first test short-circuited `EndListDrag` — it never exercised the mouse
+handlers (impossible with synthetic events: `e.GetPosition` reads the physical cursor). Added
+`RealMouseDrag_OnTheLayerList_PersistsTheReorder`: real `SetCursorPos` + `mouse_event`/`SendInput`
+against the shown MainWindow physically drag row 3 (ImgC) onto row 1 (ImgA), pumping between steps,
+then asserts the DB lands at `[Background, ImgC, ImgA, ImgB]` via the debounced save. **Both pass.**
+The mouse-down/move/up → `_dragReordered` → `EndListDrag` → `OnSceneElementsReordered` → DB seam is
+now proven with real input; a real user drag working differently would mean a stale binary (the
+Debug exe from 08:42 postdates fix commit 08:18) or a different deployment.
 
 ## ✅ Committed — Rename Recording dialog taller + full-screen hook unhooked on shutdown (2026-09-18)
 
@@ -158,6 +168,9 @@ claim — `CameraConflictProbe` reads process names only, no device handles; do
 - **Scene.Elements layer tests:** any seeded scene with `HasBackground=1` loads a healed
   `Background` element pinned at `Elements[0]` (created by `EnsureBackground` on `StagedScene` set) —
   compute expected layer orders from the live collection, never hardcode indices.
+- **Real-input injection test** (`RealMouseDrag_OnTheLayerList_PersistsTheReorder`) needs an
+  interactive desktop session: the window is shown Topmost and clicks are injected at real screen
+  coords — a covered/locked session makes the pointer no-op and the drag never lands. Fine locally.
 - `C:\tmpout` is for ffmpeg evidence artifacts; keep them out of the repo.
 
 ## Next step