[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.

Commencez par FileSystemSerDes et la valeur interne SerDes configurée, puis comparez le travail sur filesystem SerDes du Java SDK dans aws/aws-durable-execution-sdk-java#648. Examinez la couverture cloud suivie dans #527 pour la publication immuable et les scénarios de propriété et d’intégrité. Le travail est terminé lorsque des enveloppes versionnées liées au propriétaire, des lectures immuables sûres et vérifiées quant à leur intégrité, la compatibilité legacy, la préservation des modes, la resérialisation des exceptions et la documentation du cycle de vie sont assurées.

Rédigé par le modèle d'indexation à partir du texte de l'issue.