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).

TASKS.md

@@ -68,6 +68,32 @@
 
 ## Open items (at a glance)
 
+### Creator-reported batch (2026-09-26) — proof-of-concept round, recordings used as the reference
+
+The creator is **not** getting YouTube private test recordings saved, so local recordings are the
+proof of concept for compositing; the live path is assumed to share it. **Verified true, not assumed:**
+one `_framePump` is built in the `MainViewModel` ctor with a single `brandFlash:` callback, and BOTH
+`Streaming.Operations.cs:68` (go-live) and `:199` (record) call that same `StartAsync` — there is no
+second encoder path needing a "redirect". Record+simulcast is one ffmpeg with two outputs.
+
+1. ✅ **Recording save dialog: Cancel discards** — was silently saving under the default name. Enter
+   accepts the default; Cancel/Escape/X **deletes** the footage and names the file if the delete fails.
+   `MainViewModel.CompleteRecordingSave` (internal) + `ytLive.Tests/RecordingSaveDialogTests.cs`.
+2. ☐ **Brand flash must run in ALL scenes, not only while live, and must be in recordings.** Currently
+   started/stopped from `UpdateLiveVisuals()`'s `IsLive` branch, so recording-only (never go-live)
+   shows no credit at all. Ungate the presenter from `IsLive`; the pump already carries it to both.
+3. ☐ **Ticker confined to the alert box.** The announcement strip is a **global 1920×48 top overlay**
+   (`AlertOverlayLayer` comment + `BlitOverlay(…, 0, 0)`), but the creator wants it over the *Stream
+   Alerts video* — i.e. inside the `SourceType.AlertBox` rect, in preview AND output. Needs a rect
+   + scale/clip decision (see `ai.md`).
+4. ☐ **Two instances still refuse to run.** `InstanceProfile` isolates layout/auth/log/WebView, but
+   `FfmpegLocator._toolsDir` is still the hardcoded shared `%APPDATA%\ytLlive\tools` and both
+   instances can `Directory.CreateDirectory` + `ExtractBinaries` into it. Also the launch method is
+   unconfirmed: `dotnet run` while the first app holds `bin/…/ytLive.exe` dies with `MSB3027` before
+   any instance starts — that is a build-output lock, not a log conflict.
+5. ☐ **Post-session efficacy report** — on end of stream *or* recording, report what worked and what
+   failed, including the **dropped frames** the creator saw. `CurrentHealth` already tracks
+   `DroppedFrames`/`StreamDuration`; `SessionTeardownTests` is the natural home for the roll-up.
 - **TASK 3** — items 16 (Text source) + 20 (RewardEvent capture → SQLite, Alerts' persistence half) open; **17 (Alerts) is DONE via TASK 43 (2026-09-24) — native six-event alert box**
 - **TASK 9** — item 5 open (webcam identity key reconciliation)
 - **TASK 10** — Velopack update URL pending