MicroVM session: read the resume mode from the launch checkpoint (resumeBeforeDelivery) #798

Summary

microvm_session computes its resume mode from the current config on every replay. It should read the mode from the launch checkpoint, as the JavaScript SDK now does.

Details

1. The resume mode says whether each session job checks the MicroVM state, and resumes a suspended MicroVM, before delivery. _SessionScope.resume_before_delivery in microvm/session.py computes it from auto_suspend_idle_seconds and idle_policy.
2. The worker reads its idle time once, from the run hook payload of the launch. RunMicrovm sets the idle policy once, at the launch.
3. So a deploy that turns auto_suspend_on_idle off, or removes idle_policy, does not stop a running MicroVM from suspending.
4. The next job then skips the state check, and the suspended endpoint answers 502.
5. The request step retries a 502 as a MicroVM that is still starting. So the job fails with MicrovmDeliveryError only after both retry tiers.

Proposed fix

aws/aws-durable-execution-sdk-js#1042 adds a field to the session's launch checkpoint. The checkpoint format is shared, so Python must use the same field.

1. A session launch writes "resumeBeforeDelivery": true or "resumeBeforeDelivery": false in the launch step result, next to microvmId, endpoint and delivery.
2. On replay, the session reads the field instead of the current config.
3. Read the field with isinstance(value, bool). In Python True == 1, so a looser check would accept 1. A checkpoint without the field, or with a value that is not a bool, falls back to the current config.
4. microvm() single jobs write no such key. So LaunchResult.to_dict must omit it when the value is None.

The JSON shapes:

{"microvmId":"mvm-1","endpoint":"mvm-1.lambda-microvm.us-east-1.on.aws","delivery":"http","resumeBeforeDelivery":true}

{"microvmId":"mvm-1","endpoint":"mvm-1.lambda-microvm.us-east-1.on.aws","delivery":"http"}

The second shape is the microvm() checkpoint, which stays unchanged.

Raised in the review of aws/aws-durable-execution-sdk-js#1042. The JavaScript tracking issue is aws/aws-durable-execution-sdk-js#1006.