[Feature]: Deduplicate SerDes deserialization within an invocation

## What would you like?

Deduplicate repeated SerDes deserialization within a single Lambda invocation.

Async, context-dependent SerDes implementations may perform filesystem or network I/O. Repeated access to the same checkpointed result or exception currently calls `safeDeserialize()` again, even when the SerDes, serialized input, and durable payload identity are unchanged.

## Possible Implementation

- Add an invocation-scoped deserialization cache around SDK-managed SerDes calls.
- Key entries by SerDes object identity, durable execution ARN, entity identity, payload kind when available, and a digest of the serialized input.
- Store the in-flight `Promise` immediately so concurrent callers share one external read.
- Cache successful values, including `undefined`, but remove failed promises so a later call can retry.
- Bound completed entries with an LRU or weak-reference policy where practical.
- Clear all entries at the end of the Lambda invocation; do not retain a process-global cache across replays.
- Add tests for concurrent deduplication, cache hits, distinct contexts/data, `undefined`, failures, eviction, and invocation isolation.

## Is this a breaking change?

No.

## Does this require an RFC?

No.

## Additional Context

This is primarily valuable for filesystem and other external-service SerDes implementations. The Java SDK work in aws/aws-durable-execution-sdk-java#648 uses an invocation-scoped bounded cache and shares in-flight deserializations.

Start by locating the SDK-managed SerDes calls and the Lambda invocation lifecycle that should own the cache. Review how durable execution ARN, entity identity, payload kind, and serialized input are available at those call sites. Done means concurrent and repeated deserializations are deduplicated within one invocation, failures can retry, entries are bounded, and the cache is cleared before the next invocation.

Written by the indexing model from the issue text.