fix(reorder): save layer list AND preview layout immediately at drop; recording save dialog +10% (276→304)

Reorder: OnSceneElementsReordered now calls SaveLayoutNow() (was debounced
ScheduleSave) so a drag-drop persists instantly — one write stores the new
layer list (Source.SortOrder) and each layer's preview geometry (X/Y/W/H) in
the same rows. Reference: WPF ListBox drag-reorder requires an explicit persist
at drop; a debounce window lets a crash lose the drop.

Recording save dialog (RenameRecordingDialog.xaml): height 276→304 so the
Cancel/Save button row is no longer obscured; Save button named
SaveRecordingButton so the sizing test can assert it sits inside the client area.

Tests: deterministic seam test now asserts the dragged layer's geometry (preview
layout) is persisted with the new order; sizing test asserts 304 + textbox and
button-row bottoms within client area. 308/308 green.

MyMistakes.md

@@ -36,6 +36,28 @@ one rejected call inside a fallback ladder aborts the whole ladder and every unt
 
 Applied in `MediaCaptureFrameSource`'s reader-subtype ladder (2026-09-15, webcam-take fix).
 
+### "SAVE-RECORDING DIALOG IS CLIPPING CONTENT" — WHERE + HOW (RECIPE)
+
+**WHERE:** the end-of-recording modal (creator: "when I end a recording the app throws up a
+save-recording dialog with a default filename") is **`RenameRecordingDialog.xaml` at the repo ROOT**
+(title "Rename Recording", `x:Class="ytLive.RenameRecordingDialog"`). It is NOT one of the
+`*Dialog.xaml` files under `Controls/` — grep for the window title, not the filename, when the
+user names a dialog by what it does. Only fix dialogs the user actually named; do not "while I'm
+here" bump sibling dialogs.
+
+**HOW:** the dialog is `ResizeMode="NoResize"` with a fixed `Height` attribute; content client area
+≈ `Height − ~37px` of window chrome. Sizing/margin changes pushed content down in Z-order until it
+clipped — first the file-name textbox (230 too short), and after the +20% bump (→276) the creator
+found the Cancel/Save button row had ALSO been obscured. Fixed `Height` to 304 (+10% more),
+`x:Name` the last interactive control (`SaveRecordingButton`) so a test can measure it.
+
+**Verify (never eyeball-predict):** `RenameRecordingDialogSizingTests` (RealApp host) instantiates
+the real dialog, `Show()` + `UpdateLayout()`, then asserts the BOTTOM EDGE of each named control
+(`TransformToAncestor` against the content root → `TransformBounds(RenderSize).Bottom`) is ≤ the
+client `ActualHeight`. Every such dialog fix ships with that assertion for every control that was
+reported obscured. (Client-area math means the button row needs MORE slack than the textbox: its
+bottom sits deeper because of the `Margin="0,20,0,0"` above it.)
+
 ### SPIN GUARD → RESOLVED — web overlay transparency + bounding box (RECIPE)
 
 **THE ONE ROOT CAUSE THAT EXPLAINS EVERY FAILED TAKE:** WebView2's `CapturePreviewAsync`