Update BDD tests for proof-time duplicate/re-spend rejection

[jait91]

Aggregator PR #151 changes the default duplicate/re-spend behavior: submit can return SUCCESS, and the invalid spend is rejected later during inclusion proof verification with TRANSACTION_HASH_MISMATCH instead of submit-time STATE_ID_EXISTS. Update affected Java SDK BDD scenarios to assert the proof-time rejection model.

Context: unicitynetwork/aggregator-go#151 (comment)

[b3y0urs3lf]

Done — fixed in bdd-phase-0

Root cause (confirmed)

aggregator-go#151 (now merged to main) skips the finalized-duplicate lookup on the async-v2 submit path. A re-spend therefore returns SUCCESS at submit and is rejected at inclusion-proof
time as TRANSACTION_HASH_MISMATCH, instead of submit-time STATE_ID_EXISTS. Double-spend safety is unchanged — only the rejection layer moved (confirmed intended by the aggregator dev).
main aggregators (post-#151) take the proof-time path; pre-#151 builds still reject at submit.

Fix — tolerant of both builds

Rather than swapping one hard-coded submit status for another (which would break against whichever build you're not pointed at), the affected scenarios now assert the double-spend is
rejected at either layer:

pass if submit status is STATE_ID_EXISTS, or submit is SUCCESS and the inclusion proof rejects with TRANSACTION_HASH_MISMATCH.

Encapsulated in one shared invariant + Gherkin step:

• StepHelper.assertRespendRejected(context, respendTx, submitResponse) — the "never finalizes" invariant.
• Then the re-spend is rejected without finalizing (TokenLifecycleSteps) — used by the transfer/stale-token and split-burn scenarios; the bundled split double-spend steps in SplitSteps
  call the helper directly.

Additionally, the default hermetic mock was switched from StrictTestAggregatorClient to ForgivingTestAggregatorClient so the in-process CI run mirrors the merged v2 contract and actually
exercises the proof-time rejection path (the strict wrapper only ever added the v1 STATE_ID_EXISTS short-circuit). STATE_ID_EXISTS is now reserved for byte-identical idempotency tests.

Scenarios updated (14)

• token-4level-owner-actions.feature — the 8-row "Double-spend detected when reuses pre-transfer token " outline (T1a_pre … T4b_pre).
• token-transfer-edge-cases.feature — "Stale token object cannot be reused after transfer".
• token-split-transfer.feature — "Original token cannot be used after split burn", "Double-spend of a split token is prevented", "Double-spend after multi-level split is prevented",
  "Cannot spend a token after it has been split".
• token-split-advanced.feature — "Cannot transfer original token after split".

No src/ changes.

Why 14 here vs the TS suite's 9: in the Java suite the split double-spend / split-burn scenarios assert the aggregator submit status (they submit a real re-spend of the stale/burned source), so they were affected by #151 and got the tolerant assertion. The TS equivalents assert an SDK-side transferError !== null (source token burned), not the submit status, so TS left them as-is.

Validation

• Hermetic (in-process forgiving mock): full suite 351 scenarios, 0 failures, 18 skipped. The 14 take the SUCCESS → proof-time TRANSACTION_HASH_MISMATCH path.
• Against a #151-merged aggregator (single-aggregator, localhost:8080, 4-way parallel, stress/load excluded): BUILD SUCCESSFUL. The tolerant assertion also passes against a pre-#151 build
  via the STATE_ID_EXISTS branch.
• compileTestJava + cucumber pretty glue all resolve (0 undefined steps).

Mirrors the TS SDK change (state-transition-sdk-js#118).

Commit: 76a27f8 (the tolerant assertion + mock switch), on top of 96fd95a (the BDD suite).