perf(ios): broaden adaptive runner uptime preflight beyond hot taps

[thymikee]

What to build

Broaden the adaptive iOS runner readiness preflight policy beyond hot tap / tapSeries commands so more low-risk hot interactions avoid an extra uptime request when the runner has recently completed a command.

This should remain a conservative policy change, not a blanket removal of readiness checks. Startup, no-recent-success, stale-success, and commands with uncertain app-activation behavior must still run the readiness preflight. The goal is to reduce runner request count in hot interaction loops while preserving the lifecycle-status recovery path introduced by the new protocol base.

Performance target: repeated low-risk interactions should save one runner request per hot command compared with the conservative preflight path, without increasing session invalidation or command failure rate in simulator validation.

Acceptance criteria

• The policy covers at least one additional measured low-risk mutating interaction family beyond tap / tapSeries.
• First command, startup, no-success, stale-success, and conservative command paths still run readiness preflight.
• A post-send transport failure after a skipped preflight still runs lifecycle status recovery before invalidation.
• Diagnostics clearly report whether readiness preflight was used, skipped, or recovered, including command type and skip reason.
• Focused unit coverage proves the new command family skips preflight only after a recent successful runner response and remains preflighted otherwise.
• iOS simulator validation compares a hot loop before/after and shows at least one fewer runner request per hot command with no visible behavior regression.

Blocked by

• perf: adapt ios runner uptime preflight #662