fix(cua-driver): eliminate duplicate Swift bridge symbols

[injaneity]

Refs #3627

Scope

Use published screencapturekit 8.0.1, the smallest published release containing the private Swift module rename. Only the screencapturekit requirement and lock entry change: 6.0.1 -> 8.0.1. No Cua capture/recording call-site changes or other dependency updates.

Salvaged from doom-fish/screencapturekit-rs#159 via its published release. The upstream contribution by grishy renames the private module to ScreenCaptureKitCoreMediaBridge while retaining C exports. Contributor credit is preserved in the integration commit. No vendored rewrite or warning suppression.

Red -> green evidence

Agreed public boundary: a fresh real macOS Cargo release build and its linker output. scripts/ci/macos/test-swift-linker-symbols.sh creates a new Cargo/Swift build namespace every time, exposes linker messages, retains full output/toolchain provenance, and rejects duplicate-symbol diagnostics while leaving unrelated warnings visible.

• Red at 4de05b4: native build succeeded, but emitted 64 duplicate Swift symbol diagnostic lines across its link outputs. Regression check exited 1 for the intended invariant.
• Green with the dependency-only diff now committed at 60c62af: the identical fresh build/check exited 0, with zero duplicate-symbol diagnostics. Existing rpath and dead-code warnings remain visible. Green source diff was retained with the build evidence; this was tested before committing, not represented as an embedded-SHA runtime certification.
• 365 macOS unit tests passed, 2 existing ignored. Shell syntax and diff checks pass.
• Native desktop and recording evidence is now verified by the exact-candidate run below; the standalone-browser gate failed and remains unresolved.

Windows/Linux: the changed dependency belongs to platform-macos. No Windows/Linux adapter implementation changes; ordinary cross-platform CI remains required.

Exact-candidate native validation

Canonical installed Lume wrapper run 20260909T154113Z-9d6ff124 tested d1d2a7f37a8bb3a6a5686592a96487023d1f7ddc with --standalone-browser.

• Desktop: 158/158 passed; strict report/video validation passed, failure_count 0.
• Standalone browser: 15/18 passed, 3 failed. Overall wrapper exit 1; this is not a full-gate pass.
• browser_type_replace: window normalization could not verify exact frontmost window 2656; focused target/process matched, but observed ordinary frontmost window was 68.
• browser_tool_roundtrip: foreground sentinel activation could not verify window 2901; same ordinary frontmost window 68 discrepancy.
• browser_prepare_existing_profile_setup: refused because the exact Chrome remote-debugging consent sheet was not found for reconnect attempt 1; cleanup retained a surface without a semantic cancel action.
• The two activation failures occurred before behavioral recording began; the strict browser report correctly rejected missing/pending video and turn evidence. These setup failures do not establish a ScreenCaptureKit capture/recording regression; causality remains unproven.
• Evidence collected; standard daemon restoration recorded; worker stopped. No test retries, permission repairs, rebases, or VM deletions.
• Clone source: cua-driver-browser-baseline-20260908-chrome152, a browser-equipped local baseline derived from retained PR fix(cua-driver): correct macos click delivery and recording evidence #2907 / feat(cua-driver): add target-scoped post-action rediscovery #3373 workers, with Chrome 152.0.7977.83. This provenance does not negate the successful canonical desktop result.

Remaining validation

The hosted fresh-link regression passed. The workflow publishing blocker is resolved. The full native gate remains blocked. The investigation below isolates two defects across the three failing paths; fixes and regression validation remain required. No readiness is claimed.

Browser failure investigation — 2026-09-10

Two concrete defects are now isolated; do not dismiss the three original failures as unrelated CI noise or make this PR ready before fixing and validating them.

Activation (type_replace and roundtrip): both actual cases passed once in a clean, correctly authorized focused diagnostic on unchanged product/harness d1d2a7f37. In a separate controlled negative experiment, a concurrent live MCP agent cursor was moved over the foreground target. Both actual cases then failed in exact-window setup with the original focus/order disagreement. Type-replace target PID/window was 945/63; roundtrip sentinel target was 3838/120. Both remained focused with the correct front process, while the verifier reported ordinary frontmost window 61. Independent WindowServer metadata identified 61 as the driver-owned overlay (Cua Driver Local, PID 844; first layer-0 window in 483 samples). The renderer deliberately puts its transparent, mouse-ignoring window at layer 0 above the target; the verifier counts it as a competing ordinary application window. This reproduces the failure mechanism in the actual cases, not just a synthetic AppKit probe. Historical window 68 lacked ownership metadata, so its historical owner is not independently proven. Refs #3681.

Consent (existing_profile_setup): the approved Chrome main-window AX tree exposed an actual sheet with remote-debugging text and enabled, AXPress-capable Allow and Cancel buttons. Its raw-title/description rendering was AXButton "Allow" (Allow) and AXButton "Cancel" (Cancel). consent_ui::normalized_text concatenates those fields into allow allow and cancel cancel, but the matchers require exact allow / cancel; the captured buttons have no fallback identifier. Acceptance and cancellation therefore both reject valid controls. The separately enumerated consent window was AX-unresolved, but its sheet was accessible through the exact approved main window. The timeout's wording does not establish that the sheet never appeared.

The consent diagnostic ended at the harness's 25-second client timeout, not the original run's structured refusal at roughly 24 seconds; the added read-only observer may affect timing. Its captured AX fields establish the matcher defect, not an identical terminal response. Related #3409 and #3140 touch consent matching and must be reconciled before implementation; #3409's fallback requires a nonempty sheet title, absent in this captured sheet. #3288 concerns a subsequent fresh claim; closed #3440 concerned a different runtime-identity setup problem.

Evidence/provenance: separate clone cua-browser-failures-diagnostic-20260910 of the stopped failed worker; unchanged signed installed product and cached exact-source release harness; GUI Terminal launch and canonical unlock/unrestricted/watchdog/restoration helpers. Product SHA-256 f4613829d6e4eec40668bd157190ed64a43fc1e022245bccf38fcbd2f392f80d; harness SHA-256 02fbe7af2e0499699452f1713cc5fe7f0086f6cada25e1d7b0e8124c744035eb. Raw window traces, AX snapshots, RPCs, recordings, and probe sources retained locally. Standard daemon restored, worker confirmed stopped, not deleted. The initial diagnostic omitted the canonical socket export and stopped before browser setup; that setup error is retained separately and is not product evidence. No product changes, permission repairs, or full-suite retries. The unchanged roundtrip harness performed its built-in bounded sentinel recovery during the negative control; no additional retry loop was added.

Next gate: fix the two underlying defects with focused regression coverage, then certify the stable candidate. No fix, durable new regression test, or successful full-gate result is claimed by this investigation.

Underlying-fix TDD progress

• fix(cua-driver): exclude cursor overlay from foreground verification #3704 (ead27a53e718a96b7905e630f5699cd0735f781d): owned-overlay exclusion has native red -> green evidence. Both the sustained peer-cursor activation case and genuine-competing-window refusal control pass with strict recording validation. Ordinary CI is green at this head.
• fix(cua-driver): normalize repeated macOS consent labels #3706 (b3622764fdca6df606164f00d1c23b207bcaf42c): identical AX-field normalization has native red -> green evidence through the existing browser_prepare lifecycle. Exact binding, browser effects, end_session listener/UI cleanup, all external oracles, and strict recording validation pass.
• These are separate focused fix candidates based on main c07d287, not changes to this PR head or a combined full-gate pass. This PR remains blocked on review/integration and stable exact-candidate full certification. Historical failed evidence remains failed.