[Feature]: Add targeted retries for retryable SerDes failures #681

What would you like?

Add a targeted retry decorator for transient SerDes failures.

Python already exposes RetryableSerDesError, but the configured SerDes call is currently propagated after the first failure. External-storage transformations such as S3 Files/EFS access can fail transiently without requiring the entire durable operation to be rerun.

Possible Implementation

• Provide a RetrySerDes decorator, and make it usable as a stage if/when a composable SerDes pipeline is added.
• Retry only RetryableSerDesError; propagate SerDesError and other non-retryable failures immediately.
• Accept a bounded retry policy with maximum attempts and optional backoff/jitter, reusing existing retry-strategy concepts where that does not imply durable checkpoints.
• Pass the same value/data and SerDesContext to every attempt.
• Preserve the final exception type, causal chain, error data, and stack information after exhaustion.
• Ensure retries wrap only the selected SerDes transformation rather than restarting the value codec or durable operation.
• Add deterministic tests with an injected sleeper/clock so retry tests do not depend on real delays.

Is this a breaking change?

No.

Does this require an RFC?

No.

Additional Context

This builds on the existing RetryableSerDesError classification rather than introducing another recoverability mechanism. The Java SDK implementation in aws/aws-durable-execution-sdk-java#648 provides a stage-level retry decorator with the same targeted behavior.