[Feature]: Expand SerDesContext with payload and operation metadata

## What would you like?

Expand `SerDesContext` beyond `operation_id` and `durable_execution_arn` so context-aware SerDes implementations can identify the exact payload being processed.

Useful metadata includes:

- stable entity ID;
- payload kind, such as execution input/output, operation result, invoke payload, state, or exception;
- operation name, parent ID, type, and subtype;
- retry attempt number when applicable.

This enables safer external-storage ownership rules, better diagnostics, and stable naming without parsing operation IDs.

## Possible Implementation

- Add optional fields to the frozen `SerDesContext` dataclass while preserving `operation_id` and `durable_execution_arn`.
- Populate the fields for every SDK-managed serialization and deserialization path, including execution input/output, steps, child contexts, callbacks, wait-for-condition state, invoke payload/results, exceptions, and retry attempts.
- Document which fields are always present and which are operation-specific.
- Ensure the same context is passed to every attempt of a retryable SerDes operation.
- Add parity tests that capture context from each payload path and validate first execution versus replay.
- Use the richer context when implementing owner-bound filesystem envelopes and safely rebinding forwarded exception data.

## Is this a breaking change?

No. New dataclass fields should have defaults so existing custom SerDes implementations and direct context construction continue to work.

## Does this require an RFC?

Yes.

## Additional Context

The Java SDK work in aws/aws-durable-execution-sdk-java#648 passes payload kind, stable entity identity, operation metadata, and attempt number explicitly to SerDes stages.