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

## 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