[Feature]: Harden FileSystemSerDes publication and reference validation

[zhongkechen]

What would you like?

Harden FileSystemSerDes so checkpoint file references remain immutable, integrity-checked, and bound to the durable payload that produced them.

The current implementation writes to a deterministic <operation_id>.json path using "w" and stores an unversioned {"file": ...} envelope. A later serialization for the same operation can overwrite content referenced by an older checkpoint, and deserialization trusts the file path carried in the envelope.

The desired behavior is:

• publish each file payload immutably so an existing checkpoint never observes replaced content;
• use a versioned, self-identifying filesystem envelope;
• bind the envelope to its durable execution and entity identity;
• verify file integrity and path safety before reading;
• retain ALWAYS, OVERFLOW, preview, URI, and hash modes.

Possible Implementation

• Serialize the configured value SerDes once, compute a SHA-256 digest, and create a unique payload file with exclusive-create semantics.
• Include an envelope marker/version, owner durable execution ARN, owner entity/operation ID, payload type, file path, and content digest.
• On deserialization, validate the recognized envelope, expected execution directory and filename, base-path containment, symbolic links, owner rules, and content digest.
• Define explicit rules for safe cross-execution references such as invocation input/results. When an exception is forwarded through a child context, deserialize and reserialize it under the new owner rather than copying an owner-bound file envelope.
• Preserve compatibility by continuing to read the existing legacy envelope format for an appropriate migration period.
• Document storage lifecycle guidance because immutable payload publication can create orphaned files after checkpoint replacement.
• Extend the cloud coverage tracked by Add cloud-based integration tests for filesystem serdes #527 with immutable publication and ownership/integrity scenarios.

Is this a breaking change?

No. Existing constructors and configuration should remain compatible, and legacy envelopes can continue to be readable.

Does this require an RFC?

Yes.

Additional Context

The Java SDK filesystem SerDes work in aws/aws-durable-execution-sdk-java#648 uses immutable publication, versioned ownership metadata, content hashes, containment checks, and symbolic-link rejection. This issue requests equivalent guarantees adapted to Python's synchronous SerDes[Any] and configurable inner value SerDes.