iOS alert wait: the last poll can get ~30 ms and turns "no alert" into a failed read #4018

What happens

open --launch-url on iOS can return success with the warning launchConfirmationProbeFailure: "alert-read" when no "Open in" prompt appeared at all. Seen twice on iPhone 17e (iOS 27.0) while verifying #4017.

Why

awaitAppleAlert (packages/platform-apple/src/alert.ts) polls alert get until its timeout (3 s for the launch-confirmation check). After each ALERT_NOT_FOUND it sleeps for the poll interval, then starts another read with remainingBudgetMs(start, timeout). Nothing checks that the remaining budget can hold a read. The last read can get about 30 ms. The runner can't answer in that time and reports a main-thread timeout. That isn't a typed absence, so awaitAppleAlert rethrows it, and the probe reports a failed read instead of "no alert".

Required behavior

• A read that the remaining budget can't hold is not started. When the window runs out after typed absences, the result is "no alert".
• A real read failure is still reported as itself.

Found by the agent working on #3861.