[Requirement]: Map/Parallel custom-serdes cases should use a lossy transform to pin fresh-success round-trip semantics

### Operation / suite

map (a companion case is also needed for **parallel** — see below)

### Behavior to cover

The Map (`test-requirements/map/9-14.yaml`) and Parallel (`test-requirements/parallel/8-15.yaml`) custom per-item / per-branch serdes requirements currently specify a **round-tripping (symmetric)** serializer:

- `9-14` wraps `v` → `wrapped:v` → `v`
- `8-15` wraps `v` → `{"wrapped": v}` → `v`

Because serialize→deserialize is value-preserving, their `ExpectedResult` is round-trip-equal to the pre-serde values. So these cases assert only that the serde is *invoked* (via the checkpointed `wrapped:…` payload) — they never pin whether a serde's transform is reflected in the **aggregate result on a fresh (non-replay) success**.

**Proposal:** add (or amend to) Map and Parallel custom-serdes cases that use a **lossy** transform — mirroring the uppercasing serde already used in `step/1-6` and `child/3-14` — where the operation body returns the input unchanged and the serde uppercases on serialize / reads it back verbatim on deserialize. Assert that the fresh single-shot execution's aggregate result equals the **transformed** values, e.g. items `["x", "y"]` → `Result: ["X", "Y"]`, matching what replay reconstructs from the checkpointed payloads.

### Why it matters

`step/1-6` and `child/3-14` already mandate fresh-success round-trip at the language-neutral level (a fresh execution must return the uppercased value). Map/Parallel leave it unspecified, so an SDK can return the **raw body value** on the fresh run but the **serde-transformed value** on replay — a fresh-vs-replay divergence that silently corrupts downstream logic — while the suite stays green.

This is precisely the spot implementations differ: the JS SDK reconstructs Map/Parallel results by re-driving child contexts on replay, whereas other SDKs (e.g. .NET) use a parent-summary representation and must explicitly re-deserialize the just-written checkpoint on a fresh success. A lossy serde is the only thing that catches the divergence; the current symmetric serde cannot.

### Expected cross-SDK behavior

On a fresh success, a compliant SDK's Map/Parallel aggregate result should reflect each item's/branch's serde transform — identical to what replay produces from the checkpointed payloads.

Known divergence to ratify: whether all SDKs already guarantee this for Map/Parallel (as they do for step/child), or whether some apply the transform only on replay. If maintainers prefer to settle the semantics question first, this can start as a discussion / behavior dispute and convert to the requirement once ratified.

Compare the custom-serdes cases in test-requirements/map/9-14.yaml and test-requirements/parallel/8-15.yaml with the lossy serde cases in step/1-6 and child/3-14. First resolve or document the fresh-success semantics across SDKs, then add or amend Map and Parallel cases with an uppercasing transform and transformed aggregate results. Done means fresh and replayed executions require the same values.

Written by the indexing model from the issue text.