MicroVM: keep AWS request IDs in error messages, and map a CreateMicrovmAuthToken not-found #816

Summary

Port the request-ID and not-found changes of the JavaScript MicroVM operations to Python: aws/aws-durable-execution-sdk-js#1048, #1055, and #1060.

What JavaScript does now

1. A ResumeMicrovm, GetMicrovm, or CreateMicrovmAuthToken ResourceNotFoundException becomes the not-running error. Its message ends with <Operation> request ID: <id>. (#1048, #1055).
2. Every failed AWS call of the MicroVM operations keeps its request ID in the error message, in the same format. Only errors of the Lambda MicroVMs service get the label, so an STS error from a credential provider keeps its message (#1055).
3. A CreateMicrovmAuthToken ResourceNotFoundException fails the job with the not-running error, for a session and for a microvm() job over HTTP (#1055).
4. The not-found message is neutral: "A MicroVM lives at most its timeout plus 5 minutes, and never longer than 8 hours." (#1055)
5. A custom retry strategy decides on the original message of an AWS SDK error. The handler and the execution history still get the message with the request ID (#1060).

Why it matters

1. The core SDK checkpoints a step failure as its type and message. A support case for a failed AWS call needs the request ID. Only the message reaches the handler and the execution history.
2. A handler that catches the not-running error to start a new session misses a CreateMicrovmAuthToken not-found today.

First check

Verify whether the Python core SDK keeps __cause__ of a step failure. The JavaScript core drops cause, which is why JavaScript carries the request ID in the message. Python already chains the not-found error with raise not_found() from error.