[TGE] Update SDK implementation to use the new type tags

[ahtotruu]

Aggregation protocol and token data elements need to be wrapped in type tags and version number fields added like it's already done in the BFT node implementation.

[b3y0urs3lf]

Tested on top of: issue-52 merge commit (4b1fc0a). Same PR as issue-57 (commit 7b7ac23 — "#57, #55 Update inclusion proof verification, add cbor tags"). The two issues land
together because the new InclusionProof format and the CBOR tag registry are coupled.

Test environments verified:

• Hermetic — every CBOR encode/decode path
• Real bft-shard 16-shard topology — every aggregator response decoded with strict tag/version checks

Result: all 8+ tagged envelope types pass strict tag enforcement and round-trip stably.

What the PR changed

Every CBOR-serialized type now carries a distinct tag from the type registry, and every fromCbor enforces:

1. The correct outer CBOR tag (rejects wrong-tagged payloads even if the inner array shape is valid)
2. The correct version slot (slot 0 of the inner array; only version 1 accepted for versioned types; rejects 0 and 2+)
3. The correct array arity (rejects payloads of wrong length even before checking version)

Tag registry exercised in BDD:

Type	Tag	Versioned?	Arity
UnicityCertificate	39001	yes (v=1)	7
InputRecord	39002	yes (v=1)	10
CertificationData	39031	yes (v=1)	5
EncodedPredicate	39032	no (3-element, no version slot)	3
InclusionProof	39033	yes (v=1)	4
MintTransaction	39041	yes (v=1)	6
UnicityIdMintTransaction	39041	yes (v=1)	6
SplitMintJustification	39044	no (positive 2-element shape)	2
ShardTreeCertificate	(own tag)	yes (v=1)	2

BDD coverage by enforcement layer

1. Wrong-tag rejection — every type rejects payloads carrying the wrong outer tag

• cbor-envelope-tags.feature — Scenario Outline: decoded with the wrong CBOR tag throws CborError (8 rows):
  • CertificationData decoded with tag 39030 (off-by-one) → CborError containing "CertificationData"
  • InclusionProof decoded with tag 39041 (MintTransaction's tag) → rejected
  • InputRecord decoded with tag 39031 → rejected
  • ShardTreeCertificate decoded with tag 39031 → rejected
  • MintTransaction decoded with tag 39031 → rejected
  • SplitMintJustification decoded with tag 39031 → rejected
  • UnicityCertificate decoded with tag 39031 → rejected
  • UnicityIdMintTransaction decoded with tag 39031 → rejected
• cbor-envelope-tags.feature — EncodedPredicate decoded with the wrong CBOR tag throws CborError (separate scenario because EncodedPredicate has no version slot — different parser
  shape)

2. Version-slot rejection — versioned types reject anything other than v=1

• cbor-envelope-tags.feature — Scenario Outline: decoded with version throws CborError (7 rows × versions 0 and 2):
  • CertificationData v=0 and v=2 → CborError containing "version"
  • InclusionProof v=2 → rejected
  • InputRecord v=2 → rejected
  • MintTransaction v=2 → rejected
  • UnicityCertificate v=2 → rejected
  • UnicityIdMintTransaction v=2 → rejected

3. Arity-gate enforcement — array length checked before version is even looked at

• cbor-envelope-tags.feature — SplitMintJustification arity gate fires before any version concern (2 rows: arity 1 and arity 3 — both rejected with message containing "array",
  before version check). This proves the parser short-circuits on length, not on version.
• cbor-envelope-tags.feature — EncodedPredicate's correct-shape payload decodes (3-element, no version slot) — positive shape: 3-element array (no version) is valid; this scenario
  asserts the parser correctly distinguishes EncodedPredicate's no-version shape from the rest of the registry.

4. Lock-script canonicalization (round-trip stability after PR #61's predicate-as-recipient refactor)

• cbor-envelope-tags.feature — CertificationData lockScript is canonicalized and round-trips stably (encode → decode → re-encode produces byte-identical CBOR; verifies the encoder
  emits canonical form regardless of how the input was constructed)

5. StateId 32-byte enforcement (related: rejected algorithm-prefix legacy form)

• state-id-encoding.feature — StateId.fromCBOR with a -byte payload (5 rows: 0/31/33/34 fail with "data length"; 32 succeeds)
• state-id-encoding.feature — StateId.fromCBOR rejects the legacy 34-byte algorithm-prefixed form (the pre-[TGE] Update SDK implementation to use the new type tags #55 form had [algo-prefix-byte, ...32-byte-hash]; new form is bare 32
  bytes; this asserts the legacy form is no longer accepted)

6. Field-level round-trip coverage across the tagged types

• mint-transaction-fields.feature — 4-cell matrix of (justification, data) round-trips MintTransaction (tag 39041) preserving both fields byte-for-byte
• transfer-transaction-fields.feature — stateMask boundary lengths 0/1/32/64 round-trip TransferTransaction byte-for-byte
• unicity-id-mint-transaction-envelope.feature — UnicityIdMintTransaction round-trip preserves tokenId, tokenType, lockScript, recipient, targetPredicate, unicityId
• split-mint-justification-envelope.feature:
  • Round-trip preserves the underlying token and proofs byte-for-byte (encode → decode → compare CBOR of inner Token and inner SplitAssetProof list)
  • Correctly-tagged 2-element payload decodes (positive shape, no version slot) — explicit positive test that SplitMintJustification's no-version 2-element shape is the canonical
    form
  • SplitMintJustification.create rejects empty proof list (constructor invariant)
• token-cbor-roundtrip.feature — full Token round-trip (which composes all tagged sub-envelopes: genesis CertifiedMintTransaction → MintTransaction tag 39041 + InclusionProof tag
  39033 → CertificationData tag 39031 + InclusionCertificate + UnicityCertificate tag 39001 → ...)
• token-cbor-integrity.feature — truncated CBOR data and random bytes both rejected by Token.fromCbor

Why we trust the coverage is sufficient

The CBOR tag registry has three orthogonal enforcement layers (outer tag, version slot, array arity), and the BDD suite exercises each layer for each registered type:

Type	Wrong tag	Wrong version	Wrong arity	Round-trip
UnicityCertificate	✅	✅	(implicit)	✅ (Token CBOR)
InputRecord	✅	✅	(implicit)	(implicit via UC)
CertificationData	✅	✅	(implicit)	✅
EncodedPredicate	✅	n/a (no version)	✅ (positive 3-element)	✅ (canonical form)
InclusionProof	✅	✅	(implicit)	✅ (status surface)
MintTransaction	✅	✅	(implicit)	✅ (4-cell matrix)
UnicityIdMintTransaction	✅	✅	(implicit)	✅
SplitMintJustification	✅	n/a (no version)	✅ (arity 1+3)	✅
ShardTreeCertificate	✅	(implicit via UC)	(implicit)	(implicit via UC)

What's NOT in BDD (and why)

• Per-type fuzz testing of byte-level CBOR malformation — covered structurally by token-cbor-integrity.feature (truncated bytes + random bytes both rejected). Fuzz-style coverage
  on individual envelope decoders would duplicate the SDK's own unit-test fixtures (InclusionProofTest, UnicityCertificateTest).
• Cross-type tag collision — only MintTransaction and UnicityIdMintTransaction share tag 39041, and the parser distinguishes them by which fromCbor static factory is invoked
  (caller-driven, not tag-driven). This is by design; the BDD outline explicitly tests both with their own tag-mismatch row.

Moving task to done.