Proactively request OS permissions during onboarding/install instead of mid-recording

Problem

Right now the app relies on macOS surfacing permission prompts lazily, mid-recording, the first time a collector touches a protected resource (Screen Recording, Automation/Apple Events, Accessibility). This is a poor experience and a correctness risk:

• The prompt interrupts the very session the user is trying to record.
• The permission dialog itself gets captured as noise in the recording (observed: a UserNotificationCenter segment at ~4–7s of session 20260725-002501-9579844b, showing the macOS Sequoia screen-recording consent dialog).
• If the user dismisses/denies, collectors silently capture nothing (same class of silent blind spot as the un-installed terminal shell hook).
• Screen Recording in particular cannot be granted from the prompt button alone — it requires a manual toggle in System Settings + an app restart, so a mid-recording prompt basically guarantees a failed first session.

Key finding to design around: the grant follows the responsible process

macOS attributes a protected request to the responsible process (the launcher), not our binary. Evidence from testing:

• Launched via GitHub Copilot.app -> responsible process = Copilot (already authorized) -> no prompt, silent success.
• Launched via Terminal.app -> responsible process = Terminal -> macOS Sequoia periodic re-authorization fired, and the dialog named "Terminal", not "Electron"/"Skill Recorder".
• The shared, ad-hoc-signed dev identity com.github.Electron never appears in the new Sequoia screen-capture flow.

Implication: a shipped, signed Skill Recorder.app launched by double-click becomes its own responsible process -> real users will get these dialogs naming "Skill Recorder", and macOS Sequoia will periodically re-prompt for Screen Recording even after it's granted.

Proposed direction (design later)

Build a first-run / onboarding permission flow (tie into the existing privacy-doctor/electron/doctor.ts work):

1. On install/first launch, detect current authorization status for each capability the selected capture level needs (Screen Recording, Automation per target browser, Accessibility).
2. Explain why each is needed, then proactively trigger the request up front — before the user ever hits Start.
3. For Screen Recording, deep-link the user to System Settings -> Privacy & Security -> Screen Recording and guide the restart-to-apply step.
4. Re-check status on every launch and before each recording; if a required grant is missing for the chosen level, warn (and offer to open the relevant Settings pane) instead of silently capturing nothing.
5. Account for Sequoia's periodic re-authorization so it doesn't fire mid-session.

Notes / open questions

• Windows has an analogous but different story (UIA/graphics-capture consent) — the onboarding flow should be cross-platform.
• Consider having the describer/segmenter recognize and skip permission-dialog segments (UserNotificationCenter) as noise regardless.
• APIs to investigate on macOS: CGPreflightScreenCaptureAccess / CGRequestScreenCaptureAccess, AXIsProcessTrustedWithOptions, and Apple Events authorization (AEDeterminePermissionToAutomateTarget).

Filed from testing session 20260725-002501-9579844b.

Ported from https://github.com/adilei/skill-recorder/issues/1 (originally opened by @adilei on 2026-07-24).

Start with the existing privacy-doctor and electron/doctor.ts work, then trace how onboarding and recording startup currently check permissions. Map the requested macOS capabilities and the cross-platform permission differences before choosing the flow. Done means required permissions are explained and checked before recording, with settings guidance and re-checks on launch and before each session.