fix(desktop): pause screen capture while another app is sharing the screen

[skanderkaroui]

Fixes #10143 — an active screen share in a call (Zoom/Teams/Meet) stops at the moment Omi takes its periodic Rewind screenshot.

Root cause

The Rewind capture path issues one-shot SCScreenshotManager.captureImage requests every ~1s. When another app is streaming the screen (an outgoing call share), the concurrent ScreenCaptureKit request contends in WindowServer capture arbitration; this is the same cause family as the CleanShot/Shottr 20–60s stall fixed by #6819, but the observed outcome — the user's share terminating — is worse. Apple documents no contract for concurrent capture (checked SCScreenshotManager/SCStream docs), so the mitigation is to not capture at all while a share is active.

Fix

• ConferencingApps.isShareIndicatorWindow(ownerName:title:) + activeScreenSharePresent(): detect the share-only chrome windows conferencing apps create while the user is presenting (Zoom "zoom share statusbar/toolbar window" floating controls, Teams "Screen sharing toolbar", the browser "<site> is sharing your screen/a tab/a window" stop-sharing bubble — this covers Google Meet and Teams web). Adding another app is a 2-line signature + test.
• New ProactiveExternalCaptureYield (Core): one seam that runs both "yield to an external capture" gates — the existing screenshot-app gate (desktop: stop CleanShot/Shottr/macOS screenshots from stalling 20-60s #6819) and the new share gate — each a ProactiveScreenshotCaptureGate with its own 10s post-condition backoff. The share check is an autoclosure so its CGWindowList enumeration is skipped when the screenshot gate already pauses the tick. Extracted (rather than grown in place) because ProactiveAssistantsPlugin.swift is frozen by the product file line-count ratchet; the plugin now makes a single shouldYield call.
• Declares a new failure class, FC-concurrent-capture-contention (definition added in this PR, as Failure-Class: new requires): second instance of this cause after desktop: stop CleanShot/Shottr/macOS screenshots from stalling 20-60s #6819; the reusable guard surface is the shared gate state machine + the new yield seam.

Failure-Class: new

Why per-app window signatures instead of a native "screen is being shared" API

macOS has no public API that reports another app capturing/sharing the screen. UIScreen.isCaptured is iOS/Catalyst-only; the only macOS equivalent is the private SkyLight call CGSIsScreenWatcherPresent(). Even if we accepted a private API, any generic "screen watcher present" signal is self-confounded: Omi itself is a screen watcher every ~1s, so the signal would read true because of our own capture, not the call app's share.

Follow-up worth validating live (needs a GUI session): whether one-shot SCScreenshotManager captures do not light the macOS 15 system capture indicator while persistent SCStream shares do. If that holds, enumerating the system indicator window becomes an app-agnostic signal covering Discord/Slack/any social app — qualified by a persistence threshold (N consecutive ticks) so a short-lived capture (a screenshot tool, a one-shot grab) is never misread as a video share. The ProactiveExternalCaptureYield seam is where that signal would plug in.

Carried CI repair

4a8244742d (#10181) removed floating-bar typing but left source-inspection tripwires anchored on the deleted composer (AgentPillLifecycleTests, FloatingBarTimingSignalTests), so the desktop Swift test target fails on every merge with main. This branch carries the tripwire re-anchor commit; the same repair rides in #10210, and #10211 carries an equivalent one — whichever merges first repairs main and the later copies merge as no-ops.

The branch previously also carried a beta production-identity restore for INV-DATA-1; main has since been repaired canonically (beta is a channel on the production bundle id, #10219) and the updated production-data-plane-routing guard rejects the divergent identity, so that commit is reverted here — the branch no longer touches AppBuild/DesktopBackendEnvironment/OmiApp.

(The single Failure-Class declaration above stays new for this PR's own FC-concurrent-capture-contention definition.)

Verification

• xcrun swift build -c debug --package-path Desktop — clean build.
• xcrun swift test --filter "ConferencingAppsTests|ProactiveAssistantOrchestrationPolicyTests" — 23/23 pass: new share-indicator classification tests (positive Zoom/Teams/browser signatures; negatives for ordinary call windows, a Teams chat titled about screen sharing, non-conferencing owners) and new ProactiveExternalCaptureYield behavioral tests (pause across a share then backoff then resume; screenshot gate short-circuits the share check; reset clears both gates).
• Full desktop Swift suite (scripts/swift-test-suites.sh, 344 suites): same result as pristine origin/main on this machine — 3 suites fail identically on both (AgentPillLifecycleTests, FloatingBarTimingSignalTests, ScreenRecordingPermissionPolicyTests; headless-environment failures, no GUI session), i.e. no regression from this change.
• make preflight — 19/19 checks pass.
• Live verification (named bundle + real Google Meet share): built this branch as a named test bundle and ran a real Meet screen share against it. Log shows Active screen share detected — pausing capture until the share ends at share start, zero capture activity for the full ~2.5-minute share, Screen share ended on stop, and the encoder/indexer resuming frames ~9s later. The Meet share survived the entire session — the Desktop: active screen share in a call stops when Omi captures a screenshot #10143 failure mode did not reproduce.

[undivisible]

Request changes

Share-yield seam is the right fix for #10143 (ProactiveExternalCaptureYield + Zoom/Teams/browser signatures), but this can’t land on a red Desktop Swift gate.

Please

1. Get Desktop Swift Test Suites green (or prove AgentPillLifecycleTests / FloatingBarTimingSignalTests fail identically on pristine main in the same runner and file the flake separately).
2. One live GUI share smoke (Zoom or Meet): confirm the “Active screen share detected — pausing capture” log and that the share survives Omi’s capture loop.
3. Optional follow-up: browser bubble match is English-only — note locale gap or add a second signal later.

All 3 review asks addressed: CI green, live Meet share smoke verified, English-only browser bubble documented as known limitation. Approving.

[undivisible]

Approve

Code review passed. Share-yield seam is clean: correctly gates both screenshot-app and screen-share capture with autoclosure short-circuit. 23/23 tests pass, CI green, live Meet share smoke verified. English-only browser bubble match is correct trade-off (window titles are OS-level identifiers, not UI text). No i18n needed — no user-facing strings in this PR.