recording save dialog: Cancel discards the footage instead of saving the default

The creator reported that clicking Cancel in the post-recording save prompt still
saved the file under the default name: "cancel should cancel the save option,
discarding the recording" — Enter is what accepts the default.

The modal was always correct (Enter -> DialogResult=true, Cancel/Escape/X -> false).
The bug was in the caller: FinalizeRecordingAsync only overwrote `stem` when the
dialog returned true and then ran File.Move UNCONDITIONALLY, so a falsy result fell
straight through into the save. The nullable stem made "I don't want this" look
like "I accept the default".

Extracted the decision into internal MainViewModel.CompleteRecordingSave so it is
testable against real files without a frame pump:
  creatorSaved == false (Cancel/Escape/X) -> delete the temp file, leave the
      videos folder empty; a failed delete returns DiscardFailed and the toast
      names the file + folder (a "discarded" recording still on disk is worse
      than no report).
  creatorSaved == true (Save, or Enter on the pre-filled default) -> File.Move.
      A blank box still means "keep the auto name", but only on an explicit Save.

Test: ytLive.Tests/RecordingSaveDialogTests.cs — 5 facts over real temp files. The
headline asserts Cancel leaves the directory EMPTY, not merely "the stem is
unchanged"; a modal's own test cannot cover the decision it feeds.

Full suite 362/362 (the RealMouseDrag flake passed this run).

ai.md

@@ -705,6 +705,20 @@ lights when a session is actually running.
   **rename-on-stop** to `ty-…-<hh2mm2 actual length>.mp4` (`FinalizeRecordingAsync` after the pump stops &
   the file closes), numeric `-2`/`-3` suffix on collision (`UniquePath`). Length comes from `_liveElapsed`,
   which the session timer walks while `IsLive || IsRecording`.
+- **Save dialog: Cancel DISCARDS (creator ruling 2026-09-26).** The `RenameRecordingDialog` result is a
+  two-outcome decision, and it lives in the extracted `MainViewModel.CompleteRecordingSave(startPath, dir,
+  autoStem, chosenStem, creatorSaved)` (internal, so `ytLive.Tests` can drive it against real files without
+  a frame pump — see `ytLive.Tests/RecordingSaveDialogTests.cs`):
+  - `creatorSaved == false` (**Cancel / Escape / the X**) → **DELETE the temp file.** Nothing is moved,
+    nothing is left in the videos folder. A failed delete returns `DiscardFailed` and the toast NAMES the
+    file + folder, because a "discarded" recording still on disk is worse than no report.
+  - `creatorSaved == true` (Save, or **Enter on the pre-filled default**) → `File.Move` to the final name.
+    A blank/whitespace box still means "keep the auto name" — but only on an explicit Save.
+  - **The bug this fixed:** the caller used to `File.Move` UNCONDITIONALLY and only overwrite `stem` when
+    the dialog returned true, so `ShowDialog() == false` fell straight through into the save — Cancel
+    silently kept the recording under the default name. The modal itself was always correct; the
+    side effect was in the wrong place. **Any modal whose result gates a side effect must have every
+    branch handled explicitly — a falsy result must never fall through into the effect.**
 - **Folder:** default `%APPDATA%\ytLlive\recordings\`, user-overridable via `ChooseRecordFolderCommand`
   (`OpenFolderDialog`), persisted through `LayoutStore.Load/SaveRecordFolder` (`RecordFolder` key).
 - **Explicit sign-out only:** `StopStream` no longer clears the session/token. Sign out via Logout /