iOS fill can report TEXT_ENTRY_MISMATCH before the confirmation deadline #3952

Bug

On the iOS accessibility-driven fill route, replacement confirmation can return verified: false before its existing confirmation deadline. The caller then reports TEXT_ENTRY_MISMATCH, even though a subsequent read within that deadline can contain the requested text.

This is a source-level, synthetic reproduction against 45125d717b207736dd47bc7969edbff7807a6e6d; it does not depend on a particular application.

Deterministic reproduction

Exercise ReplacementTextEntryConfirmation with requested text 123456, an empty baseline, and timestamps relative to initialization:

Currently the second observation returns verified: false, so the caller stops before the later correct observation. The same early rejection occurs for an empty, focused, unidentified field whose frame changed from its baseline.

Cause

In RunnerTests+TextEntryConfirmation.swift, settled && (moved || result.verified != false || sampledAt >= deadline) permits a settled negative result whenever the observation differs from its baseline. A changed partial value or changed field frame satisfies moved; neither proves that a negative observation is final.

Required behavior

• Keep polling negative replacement observations within the existing bounded confirmation budget.
• Preserve early settled exact/unconfirmed results and identity protections.
• Preserve rejection when a mismatch persists through the deadline.
• Type once; do not clear, retype, or add mutation retries.

Completion: a synthetic regression must fail on the current rule and pass after correction, including transient partial text, a moved empty field, later exact success, and persistent mismatch rejection. No public API change or new dependency is needed.