fix(evolution): preserve Plutus data encodings on re-encode (#576)

[Kshot3000]

Summary

Fixes #576: six encodings of Plutus data that the ledger accepts came back from Transaction.fromCBORHex → Transaction.toCBORHex in different bytes, with nothing changed. Because the ledger hashes the original bytes of every datum and redeemer, a changed witness datum failed with PPViewHashesDontMatch and a changed inline datum changed the body and the transaction id.

This also adds the regression case for #580 part 2 (an empty indefinite witness set written back as a0) and fixes #580 part 3 (the CBOR guide's "canonical by default" comment). Part 1 of #580 shipped separately.

The bug, reproduced first

New regression tests failed on main for five of the six encodings, in both positions the issue names — as a witness datum (a1 04 d90102 81 [datum]) and as an inline datum in a map-form output:

• d8799fff (constructor 0, empty indefinite list) → d87980
• bfff (empty indefinite map) → a0
• d8799800 (empty list, 2-byte length header) → d87980
• 5803cccccc (3 bytes, 2-byte length header) → 43cccccc
• 5f4201024103ff (bytes in chunks) → 43010203
• an unsigned transaction with witness set bfff → a0 (CBOR: tags with 4- and 8-byte headers fail to decode, and two smaller preservation gaps #580 part 2)

The sixth encoding, c24101 (1 as a bignum), already round-trips on main — the captured-tag path in encodeUintSync handles it — so it is included in the tests as a guard rather than claimed as part of this fix. The control d8799f01ff round-tripped before and still does.

Fix

• CBOR.ts — encodeArraySync / encodeMapEntriesSync: the captured format is read before the empty fast paths. An empty array or map keeps a captured indefinite length (9f ff / bf ff) or a captured definite header width instead of always returning 80 / a0.
• CBOR.ts — BoundedBytes: the branch in internalEncodeSync now passes the captured format to encodeBoundedBytesSync. A definite header keeps its width, and an indefinite chunk layout is replayed only when it still fits the value — the chunk sizes add up to the value's length and no chunk is over 64 bytes. A stale layout falls through to the default bounded encoding, so the corruption CBOR: preservation-aware encode reuses stale chunk sizes, writing different content #575 fixed for plain byte strings is not carried into datums (the guard CBOR: Plutus data encodings change on re-encode, breaking the script data hash and the transaction id #576 asked for before this format was passed in).
• docs/content/docs/encoding/cbor.mdx: the re-encode comment now says the default keeps the original map order, matching what the same page documents for CML_DEFAULT_OPTIONS (CBOR: tags with 4- and 8-byte headers fail to decode, and two smaller preservation gaps #580 part 3).

Tests

• Transaction-with-format.test.ts: each encoding round-trips byte for byte as a witness datum and as an inline datum (plain decode/encode path), the body hash of a chunked-inline-datum transaction is unchanged (verified via CML), and the empty indefinite witness set round-trips.
• CBOR-with-format.test.ts: the four generic encodings join the round-trip vectors; hand-crafted formats pin the empty array/map behaviour; BoundedBytes tests pin the kept header width, the kept chunk layout, and both stale-layout refusals (sizes that do not add up, a chunk over 64 bytes).
• Full package suite: 1709 passed / 75 skipped / 0 failed, test files 101 passed / 1 skipped of 102 (baseline on main: 1678 passed / 75 skipped; the delta is exactly the new tests). tsc --noEmit and eslint are clean; a patch changeset is included.

---

I'm an independent builder working on Cardano tooling — not affiliated with the Cardano Foundation, IOG or Intersect.

Support my work: ADA addr1q8hnl6vl5a6k3rw3n5g3jtte696zcl76kfatzv7gpswa9r0dj7fma6klq55y4ffm7tf0em09udnyhuk4ah92pl5x9jpqjae44v · X: @kshot9000 · GitHub: Kshot3000

cc @cardano-foundation @IntersectMBO