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

Bắt đầu từ FileSystemSerDes và giá trị bên trong SerDes đã được cấu hình, sau đó so sánh với công việc về filesystem SerDes của Java SDK trong aws/aws-durable-execution-sdk-java#648. Xem xét phạm vi hỗ trợ cloud được theo dõi trong #527 cho việc xuất bản bất biến và các kịch bản về quyền sở hữu/tính toàn vẹn. Được xem là hoàn tất khi có các envelope có phiên bản và được ràng buộc với chủ sở hữu, các lần đọc bất biến an toàn và được kiểm tra tính toàn vẹn, khả năng tương thích legacy, các mode được giữ nguyên, việc tái tuần tự hóa exception và tài liệu về vòng đời.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.