Evaluate ERC1155 batch transfer support in LibFlow.flowERC1155

[thedavidmeister]

Context

LibFlow.flowERC1155 (src/lib/LibFlow.sol:122-130) dispatches each ERC1155 transfer via a separate safeTransferFrom call inside a loop. The original code carried a // @todo safeBatchTransferFrom support marker that has been split out from #305 so each TODO can be evaluated on its own.

for (uint256 i = 0; i < flowTransfer.erc1155.length; i++) {
    transfer = flowTransfer.erc1155[i];
    if (transfer.from != msg.sender && transfer.from != address(this)) {
        revert UnsupportedERC1155Flow();
    }
    IERC1155(transfer.token).safeTransferFrom(transfer.from, transfer.to, transfer.id, transfer.amount, "");
}

Question

Should flowERC1155 use safeBatchTransferFrom when multiple transfers target the same (token, from, to) tuple?

The two paths are semantically equivalent for spec-compliant tokens — the difference is gas. A batched call avoids re-entering the token contract per transfer. Tradeoffs:

• For: lower gas for multi-transfer flows; matches the EIP-1155 batch primitive that ERC1155 was designed around.
• Against: requires grouping per (token, from, to) (current code accepts arbitrary order); the current single-call loop is simpler and has been in production; receivers handle batched and per-id calls differently and may break when switched silently. Batching is a behaviour change visible to receivers via onERC1155BatchReceived vs onERC1155Received.

Decision needed

Either:

1. Adopt batching as a future flow-interface change (Vnext) — file a migration plan and write tests.
2. Pin per-transfer dispatch as final FlowV5 behaviour — close this issue with a NatSpec note in flowERC1155.

This is not a correctness defect under FlowV5; it is a deferred design question.