fix(ios): don't clear an already-empty text field (fixes fill mis-navigation)

clearTextInput unconditionally ran moveCaretToEnd (an edge-tap computed from the
element frame) + a 24-key delete burst, even when the field was empty. On a field
that repositions on focus — e.g. the Settings search bar jumping bottom->top and
revealing a 'Suggestions' list — that edge-tap used a stale frame and landed on an
adjacent row (Developer), navigating away instead of clearing. fill (replace) into
the search field went to the Developer pane (0/3 correct).

Skip the clear entirely when the field's value is already empty (placeholder
treated as empty): replacing into an empty field is a no-op, and skipping avoids
the stray edge-tap. fill into the Settings search now types correctly and stays
put: 5/5 exact (read-back + screenshot).

Author: thymikee

ios-runner/AgentDeviceRunner/AgentDeviceRunnerUITests/RunnerTests+Interaction.swift

@@ -316,6 +316,15 @@ extension RunnerTests {
   }
 
   func clearTextInput(_ element: XCUIElement) {
+    // Nothing to clear: skip both the delete burst and the moveCaretToEnd edge-tap. The
+    // edge-tap computes a point from the element frame, which can be stale after the field
+    // repositions on focus (e.g. the Settings search bar jumps bottom->top and reveals a
+    // "Suggestions" list) — tapping there navigates away instead of clearing. Replacing into
+    // an already-empty field is a no-op, so returning early is also semantically correct.
+    let existing = editableTextValue(for: element, treatingPlaceholderAsEmpty: true) ?? ""
+    if existing.isEmpty {
+      return
+    }
 #if !os(tvOS)
     moveCaretToEnd(element: element)
 #endif