test(ios-smoke): wait once more when the runner is still starting behind a deep link

[okwasniewski]

Summary

The iOS smoke test live iOS simulator fixture E2E keeps failing at wait for Automation lab, right after open --relaunch --launch-url agent-device-test-app:///automation?.... The final error is app 'com.callstack.agentdevicelab' is not running (wait_capture_stalled, APP_NOT_RUNNING). The failure screenshot shows iOS's "Open in "Agent Device Tester"?" confirmation, unanswered.

It hit #3056 once and #3057 twice today. In #3057's run the uploaded runner.log shows the cause:

1. The deep-link open succeeds at 14:51:37. The relaunch restarts the runner, and xcodebuild launches it at 14:51:33.
2. The helper's first 15 s destination wait (14:51:37 to 14:51:52) ends before the runner is up: Running tests at 14:51:54, LISTENER_READY at 14:51:55. That is runner-start readiness exhaustion.
3. answerDeepLinkConfirmation returns on runner-start exhaustion without probing (test(ios-smoke): answer deep-link prompt after readiness exhaustion #3044 gated the probe to target-discovery), so the prompt is never answered.
4. The caller's next wait reaches the now-running runner, which answers READ_TARGET_NOT_RUNNING on every read (14:51:55 to 14:52:14) until the wait times out.

The helper now waits once more after a runner-start timeout, without an alert probe. The next wait is the first that can see the pending launch: it ends on APP_NOT_RUNNING, and the existing path answers the confirmation. A second runner-start timeout still returns without probing. That keeps #3044's point: a runner that really failed costs one extra 15 s wait, not the whole 5-wait budget with probes. The miss classification moves into classifyDestinationMiss (fallow complexity); its outcomes are unchanged for every other reason.

Two test-harness files changed; production behavior is unchanged.

Validation

• ios-simulator-e2e-deep-link-confirmation.test.ts (13 pass):

  • a runner-start timeout, then a pending launch, gives wait, wait, alert get, alert accept, wait;
  • two runner-start timeouts return after the second wait with no probe.

  Both fail on main.

• pnpm check:affected --run: passed, including fallow.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[cubic-dev-ai]

No issues found across 2 files

_{Re-trigger cubic}

[thymikee]

The code looks right at 9b3995e, and all 14 checks pass. I found no conflicts, so this is ready for human review.

Not blocking: live-deep-link-confirmation.ts adds a local DestinationMissDetails type and a readinessExhaustedPhase helper, and it compares against the raw string 'runner-start'. @agent-device/contracts/wait already exports readinessPhaseOf and ReadinessPhase, so you could use readinessPhaseOf(details) behind a reason === WAIT_REASONS.readinessExhausted check. The new inline comment could also be shorter, with the one-wait rule moved into the doc block of answerDeepLinkConfirmation. Take or leave both.

I did not run the unit tests locally, so their result on the PR head and on main comes from reading the code. I could not read the #3057 runner log, so the timeline of the runner starting after the first 15 s wait comes from the PR body. CI does exercise this helper, but it does not show that this change removes the flake. Whether one extra 15 s wait is enough on a loaded CI host is best judged from the next few iOS smoke runs.