Data: reject duplicate map keys on decode and make datum hashing byte faithful

Start in packages/evolution/src/Data.ts, at the map decoding logic around L74/L88 and toDatumHash around L908-915. Read the CBORFormat WeakMap memo pattern in Transaction.ts, then add regression coverage for duplicate-key decoding and hashing a decoded non-canonical datum. Done means duplicate keys are never silently collapsed and decoded datum hashes use the original bytes when available.

Summary

Two issues with Plutus Data. (1) A Data map is modelled as a JS Map, which collapses duplicate primitive keys (last value wins). On chain a Data map is an association list that keeps every pair and resolves lookups first wins, so decoding a duplicate key map silently drops entries and can disagree with a validator. (2) toDatumHash re-encodes the decoded value and hashes that rather than hashing the bytes the datum came from, so a datum that arrived in a non canonical encoding produces a hash the node never computed.

Affected

packages/evolution/src/Data.ts map modelled as globalThis.Map (L74, L88)
packages/evolution/src/Data.ts toDatumHash (L908-915, re-encodes via toCBORBytes)
on chain semantics: IntersectMBO/plutus PlutusCore/Data.hs (Map [(Data,Data)], decodeMap keeps all pairs)
ledger hashes original memoized bytes: cardano-ledger Plutus/Data.hs

Fix

(1) Reject duplicate keys when decoding a Data map (fail closed) so silent data loss cannot happen; this keeps the ergonomic Map type. (2) Make datum hashing byte faithful for decoded datums by hashing the original source bytes, reusing the CBORFormat WeakMap memo pattern already used for Transaction (commit a0de4afa, Transaction.ts) so a decoded datum re-hashes to its original bytes. Bare integer top level datums cannot be WeakMap keyed and fall back to re-encode.

Regression test

• dup keys: Data.fromCBORHex("a200010002") currently decodes to a size 1 map dropping the first pair; after fix it is rejected (or preserved, per chosen approach), never silently collapsed
• datum hash: decode a datum that was created with a non canonical encoding, then toDatumHash must equal blake2b256 over the original bytes (the on chain hash), not over a re-encode

Must FAIL on main today and PASS after the fix.

Reference

Report 10