Given any Head protocol state and the transaction corresponding a protocol transition we should be able to observe this transition correctly even in presence of other valid Hydra Head protocol states in the used lookup utxo.

Given a UTxO with more than one entry, we can split it into two non-empty UTxO.

checkIncrement requires the claimed deposit to be its transaction's first output, so increment resolves exactly that output rather than any output of the deposit transaction. Matching by transaction id alone would build a transaction that cannot validate.

recoverTx spends TxIn depositTxId (TxIx 0), so recover resolves exactly that output. Matching by transaction id alone would read one output's datum and then build a transaction spending a different one.

Deposits ranging from trivially fitting (a few ada-only outputs) to clearly oversized (>100 distinct-policy tokens whose merged value exceeds mainnet's 5000 byte maxValSize), so rejectOversizedDeposit exercises both verdicts.

Use spendableUTxO (not 'getKnownUTxO stClosed'): the generator adds the full UTxO value to the head output so partialFanoutTx can subtract distributed values without going negative. The evaluation UTxO must match.

The spendable UTxO for the final partial fanout is the FanoutProgress head output produced by the preceding partial fanout step, so we use the 3rd element from the generator rather than 'getKnownUTxO stClosed'.