Ask before closing while recording or streaming, and finish the files first (T1.8)

[iamfatness]

Fixes #461 (T1.8). Owner decision: ask first.

Before: closing the app killed the core's whole process tree. No stop-recording was sent, so the Program MP4, every ISO and any RTMP/SRT stream were cut off mid-write. An operator who closed the app after a show lost the recording.

Now

• The dialog. Closing while anything is live asks "Stop outputs and close?", with Stop and close / Keep running. Keep running is the default. Recording, streaming, and a recording still finalizing count as live. The virtual camera alone doesn't prompt.
• Stop and close. Stops streams first, then the recording, through the existing transport path. The order matters: see Stopping Record while a stream stays up leaves recording status stuck at "stopping" (encoder restart erases the finalize result) #466 and the comment at the site. It then waits, up to 15 s, for the core's own evidence that this session finished. Evidence counts only if it arrived after the stop, for the session that was live at the close request, and from the same core generation. A stale completed, a respawned core's idle, or a missing node never counts. A dead or restarted core ends the wait immediately, logged loudly as the recording being interrupted with nothing more to save.
• If the dialog fails while outputs are live, the app still takes the Stop and close path. It never kills the files.
• Grace before the kill (app exit only). The core exits on its own when its stdin closes (JsonRpcServer.cpp EOF → loop break → joins → main returns). So app exit now closes stdin, waits 2 s, and only then kill-trees. The supervisor keeps draining the retiring core's stdout, or a full pipe would wedge its clean exit. Leftover child processes are swept after the exit. Leave-meeting, respawn and failure paths still stop immediately. The whole close fits inside the 5 s / 6 s shutdown budget, and a test pins that.
• Code. New focused types: CloseGuardPolicy (pure), CloseGuardFlow, and OutputShutdownCoordinator. StudioViewModel and MainWindow only forward.

Review. One task review (4 Important, 9 Minor) and two fix rounds. Scoped re-review 1 found N1: Record and Stream together always hit the 15 s timeout. Scoped re-review 2 approved it with no findings.

Tests. WinUI 1409/1409. MediaCore 2171/2171, 3 back-to-back runs. The app-exit tests are structural, with no wall-clock assertions, and passed 5/5 with every core pinned busy.

Known gaps (tracked)

• Stopping Record while a stream stays up leaves recording status stuck at "stopping" (encoder restart erases the finalize result) #466, core: stopping Record while a stream stays up erases the finalize result. This PR works around it only on close. A stream START still in flight at close time waits the full 15 s, though the file is still finalized.
• Zoom leave order: on app close the core still terminates the Zoom engine instead of running Leave → stop_raw_media. That needs a core change.

Required before merge: live checklist (owner, test build stopped, quiet machine)

1. Idle close: no dialog. launch.log shows media core exited on its own or …killed. Note which, and the time.
2. Recording, close, Keep running (try mouse, then Esc, then Enter): the app stays up and the recording continues.
3. Recording, close, Stop and close: the log shows outputs finished after …ms. The Program MP4 and each ISO play, and ffprobe reads a duration.
4. Record AND stream, close, Stop and close: the log shows outputs finished after …ms, not the 15 s timeout.
5. Close pressed 3× while the dialog is open, and again during the wait: each is logged as ignored.
6. Close from the taskbar while minimized: the window is restored, then asks.
7. Streaming only to one RTMP/SRT destination, then Stop and close.
8. Crash proof (the T1.7 check): zero new CoreVideoPro.WinUI.exe.*.dmp files and zero Application Error 1000 events across all runs.

🤖 Generated with Claude Code

https://claude.ai/code/session_01SAB8v62BEV8ihmaeGhhtY9

[iamfatness]

Live checklist: all 8 checks passed (2026-09-10, 21:26-21:40)

Setup

• Build: the T1.8 branch as a matched pair: shell and core built from the T1.8 worktree (core build:native-dev, D3D11 ON). Staged core hash verified.
• Meeting: the test meeting, 12 participants, Engine on.
• Driven by: the control API, window messages (WM_CLOSE / SC_CLOSE) and UI Automation Invoke.
• Streaming target: RTMP to a LOCAL ffmpeg listener on 127.0.0.1. The owner's real YouTube destination was never used. Preferences were backed up, and restored byte-identical afterwards. This dev core has no srt-output capability, so RTMP was used.

#	Check	Result
1	Idle close	✅ No dialog. media core exited on its own 171 ms after stdin closed; whole close under 300 ms.
2	Recording → close → Keep running (mouse, Esc, Enter)	✅ All three kept the app up. Recording still producing after each.
3	Recording (Program + 7 ISOs) → Stop and close	✅ outputs finished after 806ms. All 8 MP4s finalized (ffprobe duration ≈208.6 s). The last 5 s of Program and an ISO decode with no errors. Program: 12,451 frames over 208.6 s (59.7 fps).
4	Record and stream → Stop and close	✅ outputs finished after 813ms, not the 15 s timeout, so the stop-order fix (N1) holds live. The core exited on its own in 1.26 s. All 8 files finalized, with clean tail decodes. The listener received 80 MB of stream.
5	Close pressed repeatedly while the guard is active	✅ 3 presses while the dialog was open and 1 mid-transition, each logged close requested while the close guard is active — ignored.
6	Close from the taskbar while minimized	✅ The window was iconic → SC_CLOSE → dialog shown → Keep running.
7	Stream only → Stop and close	✅ The dialog said "Streaming to 1 destination". outputs finished after 295ms, then the core exited on its own.
8	Crash proof	✅ 0 new CoreVideoPro.WinUI / core / engine dumps and 0 Application Error 1000 events since the start. No leftover processes after any close.

Observed, not blocking

• Close during final cleanup. A close pressed during the final cleanup, after outputs had finished, takes the existing escape hatch (close requested while cleanup is in progress — forcing exit). That skips the core's 2 s self-exit. Files were already finalized; this behaviour predates this PR.
• Phantom recording status. A fresh core running a stream-only output reports a phantom recording (status: stopping, writerStatus: finalizing, lifecycle: null). The close guard correctly ignores it. Filed on Stopping Record while a stream stays up leaves recording status stuck at "stopping" (encoder restart erases the finalize result) #466.
• Stream health while unreachable. While the destination was unreachable, the sender kept status: live / destinationHealth: ok, even as its lifecycle cycled producing / interrupted and the supervisor restarted it. To be filed.
• Relative recording folder. Recordings/CoreVideo Pro resolves inside the app's install/publish directory. To be filed.
• Empty ISOs with Engine off. ISOs armed with Engine off write 0 frames and give no warning. To be filed.