fix(p2p)!: fix BLOCK_TXS response under proposer equivocation

[fcarreiro]

Summary

Fixes A-1070: a malicious proposer who sends two different proposals with the same archive root but different tx sets could make two honest nodes fail the BLOCK_TXS exchange and penalize each other.

In the BLOCK_TXS protocol the requester asks for txs by their index within a block (proposal), identified only by its archive root. If an equivocating proposer gives node A and node B two proposals that share an archive root but differ in their tx list, then:

• Node A (requester) asks node B for txs at indices [i, j, …] of "the block with this archive root".
• Node B (responder) resolves those indices against its version of the proposal and returns txs that, from A's perspective, are not part of the block.
• A's validateRequestedBlockTxsConsistency rejects the response and penalizes B — an honest node punished for honest behavior.

Fix

The request now carries a commitment to the full set of block tx hashes (blockTxHashesCommitment, a SHA-256 over the serialized tx hashes) alongside the archive root. The responder only serves txs by index (and advertises availability via the bitvector) when its own block's tx-hash commitment matches the request's. Otherwise it treats the request as "I don't have that block" — returning an empty bitvector and only servicing any explicitly-requested tx hashes — so neither side is penalized for an equivocation it didn't cause.

This closes the gap that the archive root alone could not: identical archive roots no longer imply identical tx sets.

Why not use proposal hash?

That would work when the BLOCK_TXS request is from a proposal, but it cannot be used when it's done from a block (e.g., in the prover node).

Changes

• BlockTxsRequest gains a blockTxHashesCommitment field and a computeBlockTxHashesCommitment helper; serialization and fromTxsSourceAndMissingTxs updated accordingly.
• reqRespBlockTxsHandler verifies the commitment before serving txs by index; on mismatch it falls back to the "block not available" path instead of returning indexed txs.
• This builds on the preceding BLOCK_TXS validation revamp commit (consistency checks on the requester side, response no longer echoes the archive root).
• Tests adapted across block_txs, block_txs_handler, and libp2p_service, plus a new handler test covering the equivocation case (different proposal under the same archive root → responder refuses to serve by index).

Closes https://linear.app/aztec-labs/issue/A-1070/malicious-proposer-can-make-honest-nodes-to-fail-tx-validation .

[spalladino]

Shouldn't we check if requestedTxHashes is non-empty before this, and if it is, return NOT_FOUND?