MicroVM session: a launch retried across a deploy can record the wrong resume mode #815

Summary

A session launch step that is retried after a deploy can record a resume mode that does not match the MicroVM it launched.

Details

1. The launch step computes the run hook payload and the resume mode from the current config.
2. A failed first attempt, for example a throttled RunMicrovm, makes the step retry, possibly in a later invocation.
3. A deploy between the attempts can change autoSuspendOnIdle or idlePolicy.
4. Both attempts send the same client token. A review probe measured the payloads: the first attempt sent autoSuspendIdleSeconds: 60, the retry sent no idle time, and the step recorded "resumeBeforeDelivery": false.
5. Suppose the first attempt created the MicroVM and only its response was lost. Then RunMicrovm either returns that MicroVM, whose worker suspends after 60 seconds, or rejects the changed parameters.
6. In the first case, the session skips the state check for a MicroVM that suspends. The next job after a suspend then gets HTTP 502 from the suspended endpoint, and fails with MicrovmDeliveryError after both retry tiers.

Not verified: how RunMicrovm treats a reused client token with different parameters.

The code before the resumeBeforeDelivery field had the same gap. So this is not a regression.

Proposed fix

Decide the launch inputs once, before the first attempt. For example, a step before the launch step records the run hook payload, the idle policy, and the resume mode. The launch step and its retries then read them from that step's result, not from the current config. The JavaScript and Python SDKs share the launch checkpoint format, so both should make the same change.