Clarify DataConverter vs PayloadConverter in data-handling docs for core-based SDKs

Background

The current data-handling.md overviews in references/dotnet, references/python, and references/typescript treat "data converter" and "payload converter" as if they were the same thing. For example:

"The .NET SDK uses data converters to serialize/deserialize workflow inputs, outputs, and activity parameters."

This is technically imprecise for the core-based SDKs (.NET, Python, TypeScript, Ruby, Rust), where a DataConverter is a composite of three sub-components:

• PayloadConverter — converts values ↔ bytes (this is what actually performs serialization)
• PayloadCodec — bytes ↔ bytes transformation (e.g. encryption, compression)
• FailureConverter — converts exceptions ↔ serialized failures

This is distinct from Go and Java, where DataConverter is the serialization interface (methods like ToPayload/FromPayload). In those SDKs, DataConverter plays the role that PayloadConverter plays in the core-based SDKs, and codecs are layered separately via CodecDataConverter.

Because developers (and AI skills using these docs) naturally assume "data conversion" works identically across SDKs, the current framing causes confusion. The Go and Java overviews are already accurate; the three core-based SDKs need updates.

See reviewer context: https://github.com/temporalio/skill-temporal-developer/pull/39#discussion_r... and the canonical description in https://github.com/temporalio/sdk-dotnet?tab=readme-ov-file#data-conversion.

Scope

Update these three files, applying the same depth of treatment to each:

• references/dotnet/data-handling.md
• references/python/data-handling.md
• references/typescript/data-handling.md

Do not change references/go/data-handling.md or references/java/data-handling.md — their current framing is accurate for those SDKs.

Detailed changes per file

For each of the three files above:

1. Rewrite the Overview section

Introduce the three-layer model explicitly. Suggested structure:

The SDK uses a DataConverter to move values between the SDK and the Temporal Service. A DataConverter is a composite of three sub-components:

• PayloadConverter — serializes values to/from Payload bytes (the default handles null, byte arrays, Protobuf messages, and JSON-serializable types).
• PayloadCodec — transforms payload bytes (e.g. for encryption or compression).
• FailureConverter — serializes exceptions/errors to/from Temporal Failure protobufs.

Most customization happens at the PayloadConverter layer. Encryption and compression belong in a PayloadCodec. Custom exception serialization belongs in a FailureConverter.

Adjust wording per-SDK to match idiomatic terms (e.g., Python uses failure_converter, TypeScript uses failureConverter, .NET uses FailureConverter).

2. Rename "Default Data Converter" → "Default Payload Converter"

The existing section that lists supported types (null, byte[], Protobuf, JSON, etc.) is describing what the default payload converter supports, not the DataConverter as a whole. Rename the section and adjust the leading sentence accordingly.

3. Review code examples

Make sure customization examples show the three-layer structure clearly — e.g., that overriding serialization means replacing the PayloadConverter inside DataConverter.Default, not replacing the DataConverter itself. (The current .NET example is already correct here; verify Python and TypeScript.)

4. Cross-reference

Add a short note in each updated overview that Go and Java use a different model (their DataConverter is the serialization interface) so readers don't transfer assumptions. One sentence is enough; avoid going into detail.

Out of scope

• Go and Java data-handling.md files.
• Changes to the actual SDK code or sample repos.
• The core/data-handling.md file (if it exists) — to be reviewed separately.

Acceptance criteria

• Overviews in .NET, Python, and TypeScript data-handling.md files describe DataConverter as the three-layer composite, with PayloadConverter identified as the serialization layer.
• "Default Data Converter" → "Default Payload Converter" rename applied where the section describes payload-type support.
• Each of the three files has a one-line note that Go/Java use a different model.
• Go and Java files are unchanged.
• Code examples remain accurate and compile-ready.

Start with the Overview and default converter sections in references/dotnet/data-handling.md, references/python/data-handling.md, and references/typescript/data-handling.md. Compare their terminology and examples with the unchanged Go and Java files, then verify each updated file explains the three-layer model, includes the Go/Java distinction, and leaves the out-of-scope files unchanged.