iOS: type/fill still reads its pre-focus element after the focus tap, ending the runner session

[thymikee]

Summary

#3237 removed the post-dispatch element reads from the tap command (#3060). The report's fill @e6
row is a different seam and still fails: XCTEST_RECORDED_FAILURE "while executing type", measured at
4.5 s, separately from the tap rows at 7.7–12.8 s.

Same root mechanism — an element that stops answering the query that resolved it once it takes focus —
different owning path, so it was left out of #3237 to keep that change inside one command family.

Where the failure comes from

The type/fill focus path reads an element handle it resolved before its own focus tap, and the reads
live after the tap:

• RunnerTests+TextEntryFocus.swift#focusTextInputForTextEntry(app:x:y:) resolves the input with
  textInputAt(app:x:y:) (line 122), dispatches a focus tap, then builds its target from
  textEntryRefreshPoint(for:), which reads element.frame (lines 140 and 160, helper at 165).
• RunnerTests+TextEntry.swift#moveCaretToEnd(element:) reads element.frame before the caret edge-tap,
  reached from clearTextInput on a replacement fill.

.type is in the interaction group, so convertsRecordedFailure turns a recorded issue into
XCTEST_RECORDED_FAILURE, and the dispatch path invalidates the target with reason
xctest_recorded_failure. The report measured fill @e6 failing with "while executing type" in 4.5 s; it
did not measure whether that command's own focus tap landed, so this issue's premise is that the failure
comes from these reads rather than from the typing itself, which the first commit must confirm.

Which of these reads the report's fill actually reached is not established here. Measure it first: a
failed read records Failed to get matching snapshot: No matches found for … from input {(TextField)},
and safely catches an exception, so a read may also be swallowed rather than recorded.

Not in this list, because it cannot record: the witness read
safely("LAST_TAPPED_TEXT_INPUT_EXISTS", false, { element.exists }) (RunnerTests+TextEntryFocus.swift:52)
does become reachable on an unqueryable field once #3237 books the witness from pre-dispatch facts, but
exists was measured to record nothing on a handle whose element had left its query. It is a correct
fail-closed check, not part of this seam.

This is not the contained-probe path, and widening containment is not the fix: textInputAt reaches
queryTextInputs through safely, not through containingTextInputProbeIssues, and
testTextInputProbeContainmentExcludesRequiredReadsAndLaterIssues pins that a required read's failure
belongs to its caller.

Required behavior

#3237 settled this on the tap route by reading the element through snapshot() instead of
element.elementType/element.frame: the same query answer, delivered through the throwing channel,
which records nothing. Measured on a handle whose element had left its query — snapshot() records 0 and
throws 10008, where .elementType and .frame each record 1 and raise.

• Route textEntryRefreshPoint(for:) and moveCaretToEnd(element:) through a snapshot() read for the
  type and frame they need. Where a stale frame cannot be trusted, the repo already refuses the shape:
  clearTextInput's comment says an edge-tap computed from a frame the field moved after records a
  failure or navigates away, so degrade to a route that needs no point or refuse with a typed reason
  rather than dispatching one.
• Keep every read that must distinguish absence from failure on probeTextEntryInput, which is what tells
  a proven no-match from a read that could not answer.
• A fill whose field genuinely did not take focus must still fail, and a genuinely recorded failure must
  still invalidate and surface. This removes reads that describe work already done, not evidence of work
  that failed.

Observable completion conditions

• A regression test on the --agent-device-text-entry-unqueryable-on-focus fixture added in fix(ios): stop a tap's post-gesture lookup from recording an XCTest failure (#3060) #3237 drives
  type/fill through execute(command:) and asserts the command succeeds or fails with a typed reason
  and that didRecordXCTestFailure(since:) is false. It must be red before the change, showing which read
  records the issue.
• --agent-device-text-entry-moves-on-focus still passes: a refresh point carried from a pre-focus
  identity must not retarget a field that moved, which is what TextInputAtPoint.identity and a target's
  boundIdentity already guard.
• pnpm check:xctest-selection keeps every new case reachable by a lane, and the iOS PR lane stays green.

Dependencies

• Prerequisite: fix(ios): stop a tap's post-gesture lookup from recording an XCTest failure (#3060) #3237 (the tap-side fix, and the fixture this issue's test builds on).
• Related: iOS: tapping a Flutter password field records an XCTest failure and restarts the runner, although the tap lands #3060 (the report), investigate(ios): confirm historical XCTest tap-failure storm root cause #1599 (narrow-issue policy), A failed selector query cannot be told apart from a true negative, and it ends the session without saying so #2273 (a failed selector query
  indistinguishable from a true negative), fix(ios): corroborate recorded tap outcomes #1605 (tap-failure corroboration).

Not in scope

Daemon tap-failure corroboration still compares an identity that includes the unstable element type, so
ios_tap_failure_corroboration_identity_mismatch remains the outcome whenever any seam records a tap
failure. That is the report's second ask and needs its own change to
src/daemon/interaction/internal/interaction-ios-tap-outcome.ts; do not fold it in here.

---

Line numbers above are as of a6f6af1 in #3237, which added a doc comment to RunnerTests+TextEntryFocus.swift and shifted them by a few lines. moveCaretToEnd is RunnerTests+TextEntry.swift:398 there.