[Feature]: Harden FileSystemSerDes publication and reference validation

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

Start at FileSystemSerDes and the configured inner value SerDes, then compare the Java SDK filesystem SerDes work in aws/aws-durable-execution-sdk-java#648. Review the cloud coverage tracked by #527 for immutable publication and ownership/integrity scenarios. Done means versioned owner-bound envelopes, safe immutable and integrity-checked reads, legacy compatibility, preserved modes, exception reserialization, and lifecycle documentation.

Written by the indexing model from the issue text.