feat(cli): add --disable-meeting-detector to skip v2 meeting watcher

[rhodium-inc]

Summary

Add an opt-in --disable-meeting-detector CLI flag (and matching disableMeetingDetector settings field) that skips the v2 meeting detector's UI scanner.

Motivation

The v2 meeting detector walks every running process's accessibility tree every 5 seconds to detect Zoom/Teams/Meet call control elements. Great for users who want automatic meeting tracking.

For tools that don't consume meeting state (task-mining tools, headless analysis pipelines, agents that only care about accessibility_text and ui_events), the scanner is pure overhead — the 5s process enumeration + AX tree walk shows up as visible CPU bursts on lower-tier machines.

Related user friction: Discord reports (e.g. bluetooth headsets being forced into HFP mode by always-on mic capture) show that users sometimes want to opt out of the meeting-detection stack altogether. This flag offers that opt-out path.

Behavior

• Default: false — no change for existing users
• When set:
  • MeetingDetector is never instantiated (the existing disable_audio branch is extended)
  • The watcher is never spawned (gated by if let Some(meeting_detector))
  • Startup log prints: meeting detector disabled via --disable-meeting-detector
  • The audio pipeline's in_meeting override flag stays false

Implementation

• `screenpipe-config`: `RecordingSettings.disable_meeting_detector` (persisted to settings.json via `disableMeetingDetector`)
• `screenpipe-engine/cli`: `--disable-meeting-detector` flag on `record` subcommand
• `screenpipe-engine/recording_config`: `RecordingConfig` propagation
• `screenpipe-engine/bin`: extend the existing meeting_detector init branch with an `else if config.disable_meeting_detector` case. The watcher start path is already gated by `if let Some(meeting_detector)` so no change is needed there.

Validation

• `cargo build --release --target x86_64-pc-windows-msvc --workspace --exclude screenpipe-rfdetr-mlx` passes on Windows
• `screenpipe record --help` shows the new flag
• Run with `--disable-meeting-detector --disable-audio` confirmed:
  • Startup log prints `meeting detector disabled via --disable-meeting-detector`
  • No `meeting scanner: pid=...` log lines (the 5s scanner is silent)

Context

Companion PR to #3385 (--disable-snapshot-compaction). Both are small, isolated CLI flags for task-mining / headless-recording use cases. Submitted separately to keep review easy.

[louis030195]

@rhodium-inc why not just disabling audio? also can u resolve conflicts

[rhodium-inc]

Hi @louis030195 — thanks for the quick look!

--disable-audio would also turn meeting detection off, but the use cases here are ones where users want audio capture/transcription on while skipping the meeting metadata layer:

• Task-mining / activity analytics: we use accessibility_text + ui_events + audio transcripts to reconstruct work sessions, but we don't consume meetings / in_meeting state. The 5s process-enum + per-process AX walk is pure overhead for that workload, and it shows up as visible CPU bursts on lower-tier hardware.
• Headless / agent recording: same pattern — full event stream wanted, meeting watcher unwanted.
• Audio-on but meeting-detection-off: a slice that already gets asked for in Discord (e.g. bluetooth users wanting to keep audio while reducing always-on detection state).

So it's the audio-on / meetings-off complement to --disable-audio's audio-off path. Same shape as #3385 (also "I want most of the pipeline, but not this one heavy worker"), and the implementation just extends the existing disable_audio → meeting_detector = None branch with an else if disable_meeting_detector.

Rebasing onto main now to clear the conflict (#3385 touched the same RecordArgs / RecordingSettings / RecordingConfig structs).