Diagnose recurring multi-minute Settings replay click in iOS Smoke

Start with the 01-settings.ad replay and the exact-head iOS runs linked in #2936, #2937, and #2938. Inspect the existing request/session diagnostics around click General, then run a live iOS replay to identify the slow phase and whether the action occurred. Done means the phase evidence explains the delay and a focused fix or evidence-backed disposition removes the repeated cost without masking failure.

Purpose

Reduce a recurring multi-minute delay in the iOS Smoke Settings replay and determine whether its successful click General response reflects a completed interaction.

Evidence

Three independent exact-head PR runs on 2026-09-24 show the same pattern in 01-settings.ad: the first attempt reports step 3 click General as successful after 143.840 s, 191.076 s, or 165.128 s; step 4 then times out after 5 s waiting for About, Software Update, or the expected Settings text. The retry succeeds in 30.5 s, 23.6 s, or 14.8 s respectively.

• #2936 iOS job: click 143.840 s, replay 234.3 s including retry.
• #2937 iOS job: click 191.076 s, replay 242.8 s including retry.
• #2938 iOS job: click 165.128 s, replay 216.1 s including retry.

The recorded replay timing establishes the delay and failed wait; it does not establish which internal click phase consumed the time or whether the tap landed. The #2936 failed wait request log includes a simulator-target-discovery-pending bridge fallback, but successful click requests did not retain equivalent phase diagnostics.

Required behavior

• Attribute the click time to target resolution, snapshot/bridge acquisition, XCTest transport, tap synthesis, and post-action work using existing request/session diagnostics or narrowly scoped new timings.
• Determine from a live failing attempt whether General was actually activated before reporting click success; repair the owning path if success can be reported without the action, or bound an optional pre-action probe beneath the operation it precedes.
• Preserve the retry as failure containment while diagnosing; do not treat the retry as proof of click correctness.

Completion

• A live iOS run captures enough phase evidence to explain the 143–191 s first-attempt clicks and the subsequent failed wait.
• A focused fix or an evidence-backed infrastructure disposition removes the repeated multi-minute cost without hiding a failed action. Compare exact-head iOS runner time and replay step timing against the linked runs.

Depends on no current PR; this is separate from #2936's depth-frontier diagnostic.