feat(limrun): press the iOS home button on Limrun instances

[jbroma]

Summary

home now works on Limrun iOS. It was refused with "Limrun iOS direct sessions do not expose home yet", but Limrun's iOS client presses the hardware home button through performActions (buttonDown/buttonUp, button: 'home'), the same batch call the provider already uses for double tap and long press.

agent-device home   # on a Limrun iOS session: the app goes to the background, the home screen shows

• LimrunIosInteractor.home() sends one press-and-release batch.
• The iOS system-button fact admits home; app-switcher stays refused.
• The Limrun docs list the home button.

6 files.

Validation

f29d4a8e8 only fixes a code comment; pnpm check:affected --run passes on it.

At 26016baab:

• pnpm check:affected --run passes (11,416 related tests, eager-closure budgets).
• Live on a Limrun iOS instance attached with only LIM_IOS_INSTANCE_URL/TOKEN: connect limrun --platform ios, open com.apple.Preferences, screenshot (Settings), home (prints Home), screenshot (the home screen with the app icons).
• tester-army/e2e on the same kind of instance: device.home() then app.open() passes on iOS. The rest of the iOS suite (leases, settings, launch arguments, AI steps) passes, and the Android suite matches main.

One observation, not changed here: a snapshot taken right after home still returned the Settings tree, because Limrun iOS snapshots read the session's app rather than whatever is in the foreground.

[cubic-dev-ai]

1 issue found across 6 files

<sub>Reply with feedback, questions, or to request a fix.

Turn on auto-fix | Re-trigger cubic</sub>

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="packages/provider-limrun/src/interaction-operations.ts">

<violation number="1" location="packages/provider-limrun/src/interaction-operations.ts:334">
P3: The comment above `systemButtonUnavailable` now reads "No Limrun session exposes a hardware button", but this PR makes Limrun iOS expose the hardware home button (`home(): available` here, `LimrunIosInteractor.home()` in ios.ts). Update it to say no Limrun session exposes the action button and that only `app-switcher` still splits by leg.</violation>
</file>

[thymikee]

I reviewed f29d4a8 and found nothing to change. The home route is covered by the facts-admit and interactor-payload tests, and all 16 checks pass. The checks cover the provider-limrun facts, the iOS interactor and the docs line, but no device lane covers the Limrun home route. The live Limrun iOS run in the PR body is your account at 26016ba, and I could not re-run it. No conflicts. Nothing else stands in the way; once the maintainer is satisfied with that live run, this can merge.

The open thread on the systemButtonUnavailable comment now matches the code, so you can resolve it: #3258 (comment)

One optional follow-up: you note that a snapshot after home still returns the Settings tree, because Limrun iOS snapshots read the session's app. That is outside this PR, but it would make a good separate issue.