Fix iOS link confirmation in Mobile E2E

[ymichael]

Human comments

What was wrong

On a fresh iOS simulator, Maestro reports openLink: "bb://threads" complete before the operating system's first custom-scheme confirmation has been accepted. The app therefore remains behind the native Open in “bb”? dialog while shell-deep-link waits for shell-webview. That simulator-owned dialog survives the next flow's app stop and launch, so shell-send and shell-unreachable-server start behind the same modal and cannot see add-server-screen. The current and prior scheduled runs show the same sequence and screenshots: run 33637452626 and run 33517924818.

What changed

• Route every Mobile E2E bb:// action through one parameterized Maestro subflow. It preserves the real custom-scheme invocation, conditionally accepts the native confirmation only when it is visible on iOS, and proves the dialog is absent before route assertions continue.
• After a failed CI flow, preserve the original final screenshot, cancel and verify removal of the native confirmation, and stop the app before continuing. If cleanup cannot establish isolation, the runner stops before the next flow.
• Add runner regression coverage for successful cleanup-before-continuation and fail-closed cleanup failure.
• No assertion, timeout, polling budget, retry budget, or wrapper ceiling changed.
• The change is confined to Mobile E2E orchestration and tests. It does not alter the server/host-daemon wire, so HOST_DAEMON_PROTOCOL_VERSION is unchanged. No CLI, SDK, or user-facing configuration surface changed.

How you verified

• Fresh-main gate: clean worktree; HEAD, origin/main, and merge-base all independently verified as ab8e0a202c70525c3c935733300198dac617e3de before inspection.
• Before, focused runner regression on current main: 2 tests failed because cleanup was never invoked and the next flow always ran.
• After, focused runner regression: 2 tests passed; cleanup precedes continuation, and cleanup failure prevents the later flow.
• Current native evidence: run 33637452626's command trace records openLink("bb://threads") completed in about one second, then shell-webview failed after its unchanged 30-second assertion. Its accessibility hierarchy contains Open in “bb”?, Cancel, and Open; all three failed-flow screenshots show that same dialog. Run 33517924818 has the same screenshots and failures. In both runs shell-launch passed and the backend stayed healthy.
• Corroboration from the fully audited, closed, unmerged PR Fix iOS deep-link confirmation in Mobile E2E #2601: its equivalent helper accepted the confirmation and delivered bb://threads on iOS 26.5, while the already-approved path skipped the conditional tap. That prior result was treated as corroboration, not as this branch's local validation.
• pnpm exec turbo run test --filter=@bb/mobile --force --concurrency=2 — 38 files, 288 tests passed.
• pnpm exec turbo run typecheck --filter=@bb/mobile --force --concurrency=2 — passed.
• pnpm exec turbo run lint --filter=@bb/mobile --force --concurrency=2 — passed with four pre-existing React warnings and zero errors.
• pnpm exec turbo run build --filter=@bb/app --force --concurrency=2 — passed; 444 files precompressed.
• bash -n apps/mobile/e2e/scripts/ci-run-flows.sh, Ruby YAML parsing for all changed flows, targeted oxfmt --check, git diff --check, and a project-wide check for direct Mobile E2E bb:// openLink actions — passed.
• Every local test/build command ran on Intel host host_nwqfteeqz4 with an explicit process-group deadline and no leaked process. This host has only Apple Command Line Tools: no Xcode, Simulator runtime, Maestro, or usable Java runtime is installed. A local Release app or native-boundary run was therefore not possible; none is claimed.

AGENT GENERATED: by GPT-5.6-Sol.