Desktop exit logs omit the shutdown request source

Bắt đầu từ điểm vào dùng chung request_app_exit(AppHandle) và truy vết các caller của app-menu, applicationShouldTerminate:, tray, Tauri ExitRequested, SIGTERM và SIGHUP. Chạy cargo test -p cap-desktop --test exit_shutdown đồng thời kiểm tra các nhật ký shutdown hiện có. Hoàn tất có nghĩa là mọi lần thử thoát một cách bình thường, bao gồm cả các yêu cầu bị chặn, đều ghi lại một nguồn có cấu trúc ổn định trước các kiểm tra admission.

Summary

Desktop shutdown diagnostics do not identify what requested the exit. This makes an orderly _exit(0) look like a spontaneous crash when Cap disappears during recording or editor work, and it prevents the application log from distinguishing an app-menu Quit, native macOS/Dock termination, tray Quit, runtime exit, or Unix signal.

I hit this while investigating repeated user-visible "crashes" on the signed Cap 0.5.9 macOS build. There were no Cap .ips, .crash, .hang, or .spin reports in macOS DiagnosticReports. A controlled Quit during an active Studio recording produced FeedLocked warnings for both microphone and camera cleanup, then the 0.5.9 process performed its hard exit with status 0. The Cap log showed cleanup, but only the macOS unified log established that the exit originated from a Quit AppleEvent/menu action.

The recording/finalization admission guards merged in #2172 address the unsafe 0.5.9 lifecycle behavior on current main. This issue tracks the remaining observability gap: future reports still cannot be classified from Cap's own logs.

Reproduction

1. Launch the macOS desktop app.
2. Start a Studio recording or open an editor.
3. Request Quit from the app menu, Dock/native termination path, tray, runtime, SIGTERM, or SIGHUP.
4. Inspect cap-desktop.log.

Actual result

Direct shutdown paths converge on request_app_exit without recording the caller. The log can show cleanup and a clean hard exit, but not why shutdown began. On 0.5.9, an admitted Quit during recording additionally reached feed cleanup while the microphone and camera were still locked.

Expected result

Every graceful exit attempt should log a stable, structured source before admission checks. Blocked requests should also retain that source in the same diagnostic sequence. A report can then be classified from Cap logs alone without depending on short-lived macOS unified-log history.

Root cause

The app menu, macOS applicationShouldTerminate:, tray menu, Tauri ExitRequested, SIGTERM, and SIGHUP paths all call the same source-less request_app_exit(AppHandle) function. The runtime event has a generic pre-log and the signals have separate text logs, but the native/app/tray callers have no equivalent attribution and no common field.

Environment and evidence

• Cap: signed stable 0.5.9; compared against main at 82519d2a42a2336545a9f30133330f4d5e10ad0a (0.6.0 source)
• macOS: 26.6.2, Apple silicon M4, 24 GB RAM
• Audio: Focusrite Scarlett Solo USB, negotiated at 192 kHz stereo and resampled by Cap to 48 kHz mono
• Camera: Logitech BRIO, 1280x720 at 30 fps
• Controlled 0.5.9 Quit evidence: microphone and camera cleanup returned FeedLocked; process exit was voluntary status 0; no Apple crash report was created
• Current-main lifecycle verification: cargo test -p cap-desktop --test exit_shutdown passes all 21 tests, including recording/finalization refusal and Quit-during-Stop coverage
• Local current-main app bundle built, installed, and launched successfully

No recording names, local media paths, account data, or service URLs are included here.

Proposed fix

Thread a typed exit source through request_app_exit and emit it as structured tracing data at the start of every graceful exit attempt.