[mvanhorn]

Summary

On a Limrun iOS simulator, filling a field with Chinese or other non-ASCII text reports success while the field stays unchanged. ASCII entered the same way appears in the field. A direct value write of the same Chinese text is stored and read back by the app. Fill focused the field, selected its contents with Command-A, and then sent the string as hardware key events. Characters with no key code never become a key event, so they are dropped while the call still succeeds. An empty fill sent Delete instead of writing an empty value.

After text-entry focus arrives, fill writes the whole string with one setElementValue call, including an empty string and characters that have no hardware key. A supplied delay remains on the signature and the replacement stays a single write. type still sends key events, with per-character timing when a delay is set. The Limrun iOS docs and the text-entry tests follow that path, including no write when focus never arrives and failure when the value write is rejected.

Fixes #3819

Test plan

npx --no-install vitest run src/ios-interactor-text-entry.test.ts completed with 9 passed tests in 1 file.
Ran pnpm run test-app:install in a Linux container (localhost/osc-linux-node:22) for the agent-device LimrunIosInteractor change; it passed.

[thymikee]

Fill on Limrun iOS now depends on the server-side focused setElementValue, and this PR never ran it on a device, so it is not ready to merge at 572f2ff. packages/provider-limrun/src/ios.ts:302 leaves three behaviors unproven: whether the call replaces existing text instead of inserting, whether setElementValue("") clears the field instead of being rejected (Android setText rejects empty text), and whether the focused:true lookup works in apps that report no globally focused element, such as Flutter, which the docs and test fixtures say still fill. The unit tests mock the Limrun client, so a server that appends, rejects empty text, or cannot resolve focus passes every test and still fails on device, and fill could silently drop or append text or throw on clear.

Please run fill live on a Limrun iOS instance at 572f2ff, for example against limrun-inc/sample-native-app nameField and greetButton, and cover four cases: fill '你好' over existing 'Ada' (the field should read 你好 and the heading 'Hello, 你好!'), fill '' (the field should clear), fill on a field in an app that reports no focused element (it should succeed or fail with a typed error), and type 'Hello' (it should still append through key events). Please paste the CLI output and the read-back into the PR.

Not blocking, and fine to take or leave: the Limrun iOS docs line at website/docs/docs/limrun.md:78 and the "a fill that sent its keys" comment at packages/contracts/src/interactor-types.ts:149 should say fill writes the value without key events (so key-event handlers may not run, and type is the keystroke path), the ignored delayMs (now _delayMs) in ios.ts:280 could be noted in the Limrun help and the comment trimmed to the one fact that the selector is omitted so the server resolves focus, and the three tests at ios-interactor-text-entry.test.ts:112 share one shape and could become one table-driven test over the texts, the delay, and the empty string.

CI is green with 14 checks and none failing, but those tests never reach the device path, and I could not run the live path myself.