perf(ios): fuse scroll frame resolution and drag into one runner command

[thymikee]

What to build

Make non-tvOS iOS scroll execute as one runner lifecycle command instead of a read-only interaction-frame request followed by a mutating drag request.

The current workflow resolves the touch reference frame first, then computes and sends a drag. The new protocol base makes this a good performance target because a single command can still be command-id tracked, status-visible, and protected by lifecycle recovery if its response is lost.

Performance target: normal iOS simulator scroll should avoid the extra runner request currently used only to resolve the interaction frame, reducing latency and reducing exposure to per-command simulator transport overhead.

Acceptance criteria

• Non-tvOS scroll can resolve the interaction frame and perform the drag through a single runner lifecycle command.
• Existing scroll result shape and gesture recording metadata remain compatible with current callers.
• tvOS remote-scroll behavior is unchanged.
• Lost-response handling remains lifecycle-safe: observed accepted/started/completed/failed states are not replayed unsafely.
• Focused tests prove the single-command scroll path no longer sends a separate interaction-frame command for the common iOS path.
• iOS simulator validation shows scroll still moves the UI correctly and emits one fewer runner request than the previous interaction-frame-plus-drag flow.

Blocked by

None - can start immediately