fix(ios): verify a fill whose unidentified field moved while it kept focus

[Lanchez]

Summary

Since #3334, an iOS replacement fill fails with TEXT_ENTRY_MISMATCH when an unidentified field moves during entry, although it holds exactly the requested text, which the help says confirms the entry: identity compares exact frames, and an iOS 26 bottom search bar rises and widens as typing starts.

Each text-entry observation now records focus. When the two reads differ only in frame, both without an identifier, same type and both focused, an exact read-back verifies; anything else still fails. Identity and the settle check stay frame-strict.

Known limits: focus cannot tell a moved field from an unidentified successor at the same query index, hence exact read-backs only. A fill ending in a submit key ends editing, so a moved field still fails as before (not measured on a device).

Closes #3595. 5 files: the read-back rule, a host-app flag --agent-device-text-entry-moves-on-input, tests.

Validation

Head 30da217: pnpm check:affected --run passed. iPhone 17 Pro, iOS 26.5: the two new tests and the existing unidentified-field fill tests pass, as do the pure tests on the macOS host lane. Reverting the rule fails both new tests; dropping the focus read fails the fixture test.

Live, a React Native app's bottom search bar, two fills per relaunch, 10 relaunches:

	base 352ad62	head 30da217
iPhone Air, iOS 26.5	20/20 TEXT_ENTRY_MISMATCH on first attempt	20/20 pass
iPhone Air, iOS 27.0	20/20 pass	20/20 pass
iPhone 16, iOS 18.5	20/20 pass	20/20 pass

[cubic-dev-ai]

No issues found across 5 files

_{View guided diff | Re-trigger cubic}

[thymikee]

This looks good at 30da217. Reading the pre-change branch, the old code returned a failed fill whenever the field was not the same element, and the new check now verifies a moved, unidentified field that kept focus. The one check on this PR is green. The Swift runner unit and UI tests are not in host CI, so this relies on your simulator runs. I did not run them or the live fills, and the live table in the description is yours.

One window is left, and the PR and issue already name it. An unidentified successor of the same type, at the same query index, focused and holding exactly the requested text, now verifies. Before #3334 (0.21.24) that case was accepted anyway, so this is no regression. I did not measure whether an app's focus auto-advance, such as a one-digit-per-box code field, can create that state. On tvOS, focusBool also reads hasFocus, which is focus-engine focus and not keyboard focus. I did not check whether the fill read-back runs on tvOS.

I see no conflicts. Please confirm the 'Closes #3595' wording, and then this is ready for maintainer merge.