Use predicates instead of addresses in transactions

[martti007]

Currently java uses addresses in transactions, it needs to be changed so each transaction has recipient predicate instead.
Also mint transaction structure must be changed:

• User data is optional
• Mint justification is on root level of cbor
• Token type is on root level of cbor

Initial task is here
unicitynetwork/state-transition-sdk-js#110

[b3y0urs3lf]

Tested on top of: issue-52 merge commit (4b1fc0a). Branch bdd-phase-0 of state-transition-sdk-java.

Test environments verified:

• Hermetic (StrictTestAggregatorClient) — every mint/transfer/split path
• Real bft-shard 16-shard topology — every recipient resolved to a Predicate, no Address indirection

Result: all token-* features pass with the new Predicate-based API surface. The Address removal is comprehensively exercised because every mint and transfer scenario now passes a
SignaturePredicate (or in nametag flows, a target predicate from UnicityIdToken.genesis.targetPredicate) directly as recipient.

What the PR changed

• Address class removed — recipients are now Predicate (SignaturePredicate.fromSigningService(...)) passed directly to MintTransaction.create(recipient, tokenId, ...) and
  TransferTransaction.create(token, recipient, x, ...)
• nonce → stateMask rename — the per-state randomness field renamed across MintTransaction, TransferTransaction, and the state-hash derivation
• SplitMintJustification moved to mint root — MintTransaction.justification slot now holds the SplitMintJustification CBOR directly (previously wrapped in a SplitReason envelope)
• TokenSplit / SplitAssetProof / SplitResult restructured — TokenSplit.split(token, parser, plan) 3-arg form, SplitMintJustification.create(burnToken, proofsSet)
• EncodedPredicate is the wire form — predicates are encoded once and embedded in MintTransaction's recipient and lockScript slots

BDD coverage by area

1. Predicate-as-recipient — replaces every Address call site (~270 scenarios)

Every mint and transfer step in the suite passes a SignaturePredicate directly. The Java BDD harness's TokenUtils.mintToken(...) and TokenUtils.transferToken(...) take Predicate
recipient parameters; there is no Address indirection anywhere.

Direct exercises:

• token-minting.feature — 3 base scenarios + 2 nametag-addressed outline rows (predicate from SigningService for pubkey path; predicate from UnicityIdToken.targetPredicate for
  nametag path)
• token-transfer.feature — Alice mints a token, Alice transfers to Bob, Alice → Bob → Carol chain — all via SignaturePredicate recipients
• token-transfer-chain.feature — 4-user chain + 2-hop outline + 2 nametag-entry outline rows (predicates throughout)
• token-long-transfer-chain.feature — 10-hop and 4-hop chains with pubkey/nametag mint entry
• token-mixed-addressing.feature — 12 mixed-method chains (pubkey/nametag interleaved) — every hop resolves to a Predicate via resolveRecipientPredicate(user, method)

2. nonce → stateMask rename (round-trip preservation)

The renamed field is exercised via field-level round-trip tests across boundary lengths:

• transfer-transaction-fields.feature — Scenario Outline: TransferTransaction round-trip preserves stateMask of bytes (4 rows: 0, 1, 32, 64 bytes; each round-trips through
  CBOR and asserts byte-for-byte equality of the stateMask field)
• mint-transaction-fields.feature — 4-cell matrix Round-trip preserves both fields when (justification, data both null/data-only/both-non-null/justification-only — exercises
  stateMask preservation across all combinations)

3. SplitMintJustification at mint root (verifier sees the new layout)

The mutation matrix in split-mint-justification-verifier.feature proves the verifier reads SplitMintJustification directly from MintTransaction.justification:

• stripping the justification field → Transaction has no justification (asserts the verifier checks the mint-root justification slot)
• stripping the data field → Assets data is missing
• adding an extra asset to data not present in proofs → Total amount of assets differ in token and proofs
• renaming one proof's assetId to one not in data → not found in asset data
• mismatching one asset's value between data and tree → does not match asset tree leaf

Round-trip + invariant:

• split-mint-justification-envelope.feature — Round-trip preserves the underlying token and proofs byte-for-byte (decodes the new mint-root justification CBOR, asserts
  byte-for-byte preservation of both inner Token and inner SplitAssetProof list)
• split-mint-justification-envelope.feature — SplitMintJustification.create rejects empty proof list (constructor invariant)
• split-mint-justification-envelope.feature — Correctly-tagged 2-element payload decodes (positive shape, no version slot) (positive shape assertion: SplitMintJustification has no
  version slot, only [token, proofs])

4. TokenSplit restructure (3-arg form, full split lifecycle)

• token-split.feature — 5 scenarios: successful 2-token split, individual verification, asset-count mismatch error, asset-id mismatch error, asset-value mismatch error
• token-split-advanced.feature — 6 scenarios: split-to-different-users, recipient-can-transfer, multi-level split, CBOR round-trip of split child, non-owner-cannot-split,
  original-burned-after-split
• token-split-boundaries.feature — 3 scenarios: total-exceeds-original (error), total-less-than-original (error), minimum-value-of-1 (success)
• token-split-combinations.feature — combinatorial outline: split <1,2,3> assets into <2,3> parts (4 rows)
• token-split-transfer.feature — 7 scenarios: split-burn-prevents-original-spend, split-then-transfer-to-multiple, recipient-further-transfers, double-spend-prevention, multi-level
  (4-level) split with transfer, double-spend-after-multi-level-split, cannot-spend-after-split
• split-edge-cases.feature — 2 scenarios: 1-output split (degenerate shape), idempotent re-submission of split-mint cert request
• token-payment-journey.feature — Complete payment flow from mint through split to transfer (full use-case end-to-end)

5. Predicate canonicalization through EncodedPredicate

Since every recipient is now a Predicate encoded via EncodedPredicate.fromPredicate(predicate), the canonicalization is implicitly exercised by every mint/transfer round-trip.
Explicit assertion:

• cbor-envelope-tags.feature — CertificationData lockScript is canonicalized and round-trips stably (encode → decode → re-encode produces byte-identical CBOR for the
  EncodedPredicate-wrapped lockScript)
• cbor-envelope-tags.feature — EncodedPredicate decoded with the wrong CBOR tag throws CborError (tag enforcement on EncodedPredicate envelope)
• cbor-envelope-tags.feature — EncodedPredicate's correct-shape payload decodes (3-element, no version slot) (positive shape: EncodedPredicate has 3 elements and no version slot —
  different from the versioned envelope types)

6. Predicate-based ownership semantics (security)

• token-security.feature — Non-owner cannot create a transfer (Bob's predicate cannot unlock Alice's token; predicate verification rejects mismatch)
• token-security.feature — Previous owner cannot reclaim transferred token (Alice cannot transfer after handing off to Bob; new owner's predicate is what's encoded as recipient)
• token-4level-owner-actions.feature — 24 outline rows: every non-owner cannot transfer or use a stale pre-transfer token (predicate verification fires on every level of the
  4-level tree)
• token-4level-split-negative.feature — 31 outline rows: every non-owner cannot split a token (predicate-based authorization at each level)
• token-4level-transfer-negative.feature — 31 outline rows: every non-owner cannot transfer (predicate-based authorization)

7. Token CBOR round-trip with full predicate composition

• token-cbor-roundtrip.feature — Token round-trip across freshly-minted, post-transfer, and split-child states (the full Token CBOR composes EncodedPredicate-wrapped lockScript and
  recipient at every layer)
• token-serialization-advanced.feature — 4 round-trip scenarios across 0-, 1-, 2-, 4-hop transfer chains with 4 distinct predicates (Alice/Bob/Carol/Dave)

What's NOT in BDD (and why that's correct)

• Address.java deletion itself — there's no test for "Address class no longer exists"; the absence is enforced by the compiler when test code uses Predicate directly. Every BDD
  step that constructs a recipient does so via SignaturePredicate.fromSigningService(...) — if Address came back, the steps wouldn't compile against the new SDK.
• Internal SMT path step renumbering (SparseMerkleTreePathStep field changes) — implementation detail of the path encoding; correctness is exercised end-to-end by every
  inclusion-proof scenario in inclusion-proof-statuses.feature and every transfer that depends on path verification.
• SplitReason wrapper class removal — dead-code cleanup; the new mint-root layout is what the verifier reads, and that is exhaustively tested by the 5-mutation matrix.

Moving task to done.