feat(meeting): opt-in process-list reminder when a meeting app starts

Default off. When on, the layout polls detect_meeting_processes every 15s
with the user's app-name patterns. On a fresh match (edge-triggered — no
re-toast until the app goes away and comes back) we fire a reminder toast
that tells the user which meeting app appeared and their global hotkey. We
never start recording on this signal; the ideology rule says the user
decides. The signal is a single channel: process list match only — no mic
activity heuristic, no calendar.

Backend adds kon_core::process_watch::{list_running_process_names,
match_meeting_patterns} over sysinfo, exposed to the frontend as the
detect_meeting_processes Tauri command.

Settings ships two new fields — meetingAutoCapture (bool) and
meetingAutoCaptureApps (string[]) — with a comma-separated input in the
Output section. Default app list is ["zoom", "teams"], user-editable.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

src-tauri/src/commands/meeting.rs

@@ -0,0 +1,17 @@
+//! Meeting auto-capture — the single-signal variant.
+//!
+//! The frontend polls `detect_meeting_processes` on an interval with the
+//! user's app patterns. On a positive hit it surfaces a non-modal toast
+//! that reminds the user to start recording with their hotkey. We do not
+//! start recording from this signal — the user decides.
+
+use kon_core::process_watch;
+
+#[tauri::command]
+pub fn detect_meeting_processes(patterns: Vec<String>) -> Result<Vec<String>, String> {
+    if patterns.is_empty() {
+        return Ok(Vec::new());
+    }
+    let processes = process_watch::list_running_process_names();
+    Ok(process_watch::match_meeting_patterns(&processes, &patterns))
+}