[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 で追跡されている、イミュータブルな公開および所有権／整合性のシナリオに関するクラウド対応範囲を確認してください。完了の条件は、バージョン付きで所有者にバインドされたエンベロープ、安全なイミュータブルかつ整合性検証済みの読み取り、legacy 互換性、モードの維持、例外の再シリアライズ、ライフサイクルのドキュメントが実現されていることです。

索引モデルが issue の本文から書いたものです。