feat: confirmation dialog before stopping a recording

[nicw]

Problem

It's too easy to stop a recording: the main Stop Recording button (and its ⌘. shortcut) tore the session down on a single click, and accidental clicks mid-meeting kept ending sessions irreversibly (transcript finalizes, post-processing starts).

Change

The main Stop button now presents a standard alert — "Are you sure you want to stop recording?" — with Cancel as the default button (Return cancels) and a destructive Stop Recording button. Capture, transcription, and the timers keep running while the dialog is up; nothing stops until the explicit confirm.

Only the main button confirms. Deliberately unchanged:

Path	Why
Silence prompt "Stop & Save"	Already a confirmation
Notification "Stop Recording" action	Mirror of the silence prompt
POST /sessions/stop	Must stay scriptable; API/** untouched

Implementation: a small @Observable StopConfirmationModel owns the confirmation lifecycle (so it's unit-testable); ControlBar's shared onStop closure splits into onStopRequested (main button) and onStop (silence prompt); ContentView hosts the .alert and withdraws it via the existing isRunning onChange if the session ends through any other path (capture error, API stop, notification stop). A stale confirm racing a stop is a no-op via stopSession()'s existing re-entrance guard.

Spec and plan are included under docs/superpowers/.

Testing

• 6 unit tests on the model (confirm fires exactly once; cancel/external-end fire nothing; a pinning test guards the deliberately-unguarded confirmStop() — SwiftUI clears the alert binding before running the button action, so adding guard isPresented would silently break every confirm).
• Full suite: 100 tests in 18 suites, all passing.
• Manual checklist on a live dev build: dialog presents mid-recording with the timer running behind it, Cancel resumes, confirm finalizes normally, Return cancels, silence prompt shows no second dialog, API stop withdraws the open dialog.

Known limitation (documented in the spec): Esc does not cancel — SwiftUI drops the cancel-role's implicit Esc equivalent when the button also carries .keyboardShortcut(.defaultAction), and a button holds one shortcut. We kept the verified Return-cancels-by-default behavior rather than trading it for Esc; bail-out is Return or clicking Cancel.

🤖 Generated with Claude Code