fix: strengthen TransactionList validation in fromBytes

[rwalworth]

Summary

This PR adds stricter structural validation to Transaction.fromBytes() when deserializing a TransactionList containing multiple TransactionId groups. The changes enforce invariants that were previously unchecked: only chunked transaction types (TopicMessageSubmitTransaction, FileAppendTransaction) are permitted to have multiple groups, and for chunked types the declared chunkInfo.total must match the actual group count with sequential chunk numbers.

Key Changes:

• Reject multi-group TransactionList payloads for all non-chunked transaction types
• Validate chunkInfo.total matches the actual number of TransactionId groups for consensusSubmitMessage
• Validate chunkInfo.number values are sequential (1, 2, 3…) across groups
• Add 4 unit tests covering the new rejection cases

---

Changes

Structural validation in Transaction.fromBytes (Transaction.swift)

Two new validation blocks are inserted after the existing protoTransactionBodyEqual loop.

Block 1 — Non-chunked type guard:

Only consensusSubmitMessage and fileAppend legitimately produce multiple TransactionId groups (one per chunk). All other transaction types must have exactly one group. A TransactionList with multiple groups for any other type is now rejected with a descriptive error.

if sources.chunksCount > 1 {
    switch transactionBodies[0].data {
    case .consensusSubmitMessage, .fileAppend:
        break
    default:
        throw HError.fromProtobuf("non-chunked transaction must not have multiple transaction ID groups")
    }
}

Block 2 — chunkInfo consistency for consensusSubmitMessage:

For chunked HCS messages, chunkInfo.total declares the expected number of chunks. This is now validated against the actual group count, and each group's chunkInfo.number is checked to be sequential starting at 1.

if case .consensusSubmitMessage(let msg) = transactionBodies[0].data, msg.hasChunkInfo {
    guard sources.chunksCount == Int(msg.chunkInfo.total) else {
        throw HError.fromProtobuf(...)
    }
    for (chunkIndex, chunk) in sources.chunks.enumerated() {
        // validates chunkMsg.chunkInfo.number == chunkIndex + 1
    }
}

Note: Swift's existing protoTransactionBodyEqual already validates cross-group body consistency for all types (comparing every signed transaction against the first), which covers the equivalent of C++'s Layer 2 normalization check. No change was needed there.

Comment update (TopicMessageSubmitTransaction.swift)

Removed the stale comment on line 31 (// note: no other SDK checks for correctness here... so let's not do it here either?) and replaced it with a reference to the new validation in fromBytes.

Tests (ChunkedTransactionUnitTests.swift)

Four new rejection tests plus retention of the existing round-trip regression test:

Test	Scenario
test_fromBytes_rejectMultiGroupNonChunked	CryptoTransfer with 2 groups → throws
test_fromBytes_rejectChunkCountMismatch_totalTooLow	2 groups, chunkInfo.total = 1 → throws
test_fromBytes_rejectChunkCountMismatch_totalTooHigh	2 groups, chunkInfo.total = 3 → throws
test_fromBytes_rejectOutOfOrderChunkNumbers	2 groups with swapped chunkInfo.number → throws
test_ToFromBytes	Legitimate 2-chunk message round-trips correctly ✅

---

Testing

swift test --filter ChunkedTransactionUnitTests

All 5 tests pass, including the pre-existing round-trip test.

---

Files Changed Summary

Category	File
Core validation	Sources/Hiero/Transaction.swift
Comment update	Sources/Hiero/Topic/TopicMessageSubmitTransaction.swift
Tests	Tests/HieroUnitTests/ChunkedTransactionUnitTests.swift

---

Breaking Changes

None. All public APIs remain unchanged. The new validation only affects Transaction.fromBytes() when given a structurally inconsistent TransactionList. Legitimate multi-chunk TopicMessageSubmitTransaction and FileAppendTransaction payloads continue to deserialize correctly.

[ddeskov-limechain]

LGTM