feat: video capture frontend — consent, notifications, activity stream & settings

[christineyan4]

Summary

Adds the complete frontend experience for the video capture capabilities (screen.record and camera.clip). The backend recording commands already existed but had no UI feedback, consent flow, or user-facing controls.

Demo

📹 Video walkthrough

What's included

1. Recording state tracking (NodeService.cs)

• RecordingType enum (Screen, Camera), RecordingStateEventArgs class
• RecordingStateChanged event with IsScreenRecording/IsCameraRecording properties
• Wrappers around OnScreenRecord and OnCameraClip that emit state start/complete/error

2. Toast notifications

• System toasts for recording start, complete, and error (both screen & camera)
• 10 new resource strings across all 5 locales

3. Activity stream integration (App.xaml.cs, ActivityPage.xaml)

• Recording events appear in the activity feed with emoji indicators (🔴 recording, ✅ complete)
• Fixed WinUI color emoji clipping issue with separate TextBlock in StackPanel layout
• Added Icon property to ActivityStreamItem

4. Recording consent dialog (RecordingConsentDialog.cs)

• Standalone WindowEx with Mica backdrop and custom titlebar
• Separate consent per capability (screen vs camera)
• TaskCompletionSource pattern for async result
• SetForegroundWindow + HWND_TOPMOST for reliable z-order
• Deny = block this request only (re-prompts next time)
• Allow = persist consent, skip dialog for future requests

5. Privacy settings UI (SettingsPage.xaml)

• New "Privacy" expander with screen/camera recording toggles
• Live-updates via SettingsManager.Saved event when consent changes externally
• "✓ Saved" indicator when auto-updated by consent dialog

6. Localization

• All new strings localized across en-us, fr-fr, zh-cn, zh-tw, nl-nl
• Passes LocalizationValidationTests (all locales have matching keys)

Testing

• All 1220 shared tests + 389 tray tests pass
• Manual verification: consent flow (allow/deny), toast notifications, activity stream, settings toggle sync, permission persistence across restarts, z-order behavior

[shanselman]

Thanks for adding the recording UX surfaces. I think the consent model needs changes before this can merge.

Two blockers stood out:

1. Concurrent recording requests can show multiple consent dialogs and race unsynchronized SettingsManager.Save calls, so consent state can be lost or applied unpredictably.
2. The sticky consent flags can be granted from Settings and then future recording requests proceed without a fresh prompt. For camera/screen recording, that needs a clearer privacy model: settings text should make the behavior explicit, future recordings should have reliable user-visible indication, and consent updates should be serialized/atomic.

[christineyan4]

Thanks for feedback! Pushed changes addressing these blockers--fixed the consent dialog race condition and added a lock on SettingsManager.Save() to serialize concurrent writes. Also updated the Settings text to make the sticky consent behavior more explicit.

Also added a 3-2-1 countdown overlay before recording, to give users a clear visual cue that recording is about to start, whether thru camera or on screen.

[shanselman]

Thanks so much for the quick follow-up, Christine — this is really close. 🙏

Bot-assisted note from Scott's triage pass: I can see you addressed the big issues we called out around consent dialog coalescing and serializing SettingsManager.Save(). That moved the PR a lot closer.

I think there are just a few small things left before we can comfortably clear the requested-changes review:

1. CI needs one more pass — build-extension (arm64) is failing and build-extension (x64) was cancelled. This may be transient, but we need those green or a clear explanation.
2. Consent lock cleanup — the current _consentLock flow manually releases the semaphore in multiple paths and uses CurrentCount in the catch block. Could you refactor that so we don't rely on CurrentCount/best-effort release? The intent looks right; I just want to avoid an over-release/race edge case.
3. Sticky consent copy — since clicking Allow persists future recording consent until changed in Settings, could the dialog copy say that explicitly? Something like “Allow future screen/camera recordings until disabled in Settings” would make the privacy model clearer.
4. Settings page dirty state — external consent saves can still update the recording toggles while the Settings page has unsaved edits. A small dirty-state guard, or only applying external consent updates when the page is clean, would make this safer.
5. Focused tests if practical — even one test around consent coalescing or settings-save behavior would help lock this down.

Again, thank you — the feature direction is good, and the latest commits show exactly the kind of quick iteration we were hoping for. This feels like a small cleanup pass away rather than a major rework.