[Feature]: Expand SerDesContext with payload and operation metadata

[zhongkechen]

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.