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

从 FileSystemSerDes 和配置的内部值 SerDes 开始，然后对比 aws/aws-durable-execution-sdk-java#648 中 Java SDK filesystem SerDes 的工作。审查 #527 中跟踪的云覆盖范围，涵盖不可变发布以及所有权/完整性场景。完成的标准是具备带版本且绑定所有者的 envelope、安全的不可变且经过完整性检查的读取、legacy 兼容性、保留的模式、异常重新序列化以及生命周期文档。

由索引模型根据 Issue 内容生成。