[Feature]: Add targeted retries for retryable SerDes failures

## 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.

Start by locating the existing RetryableSerDesError classification and the configured SerDes call described in the issue; compare the stage-level behavior in aws/aws-durable-execution-sdk-java#648. Done means only retryable SerDes failures are retried with bounded, deterministic policy tests, while non-retryable errors and final exception details remain unchanged.

Written by the indexing model from the issue text.