Tezlink/Compatibility: Makes Tezlink receipts compatible with Tezos

What

Always return an empty vector when encoding Tezlink errors.

Why

Currently, the Tezlink receipt is compatible with Data_encoding but only when the operation is successful. In the encoding operation.data_and_metadata there's no specific format for the errors and the encoding just accepts any serialized json.

But the derive NomReader/BinWriter doesn't encode OperationError as a generic json so the decoding is failing in the node.

For now, we just ignore Tezlink errors as it's simplier to be Tezos compatible and those errors are mainly used for debugging.

How

Implement BinWriter and NomReader for the list of OperationError to always return empty list to be compatible with Data_encoding when decoding operation.data_and_metadata

Manually testing the MR

Start a Tezlink sandbox:

make octez-evm-node
make -f etherlink.mk evm_kernel.wasm
RUST_LOG=octez_evm_node_wasm_runtime::write_debug=trace octez-evm-node run tezlink sandbox --data-dir ~/sequencer --kernel ~/path/to/tezos/evm_kernel.wasm --tez-bootstrap-account <SOURCE_PUBLIC_KEY>

Makes an invalid transfer with octez-client (it's possible because there's no validation yet so octez-client will thinks that the operation is applied), 100000000000 tez is too big even for bootstrap account

octez-client -E http://localhost:8545/tezlink --wait none transfer 100000000000 from <SOURCE> to <DST> --burn-cap 0.06425

Now if you check the log of the sandbox, you should see a log to know in which block your transaction (here my operation is at block 5):

[2025-07-16T12:02:49Z INFO  octez_evm_node_wasm_runtime::write_debug] Storing block 5 at 2025-07-16T12:02:49Z containing 1 transaction(s) for 0 gas used.

Now if you check at the block with your operation (for me it's 5):

curl -X GET "http://localhost:8545/tezlink/chains/main/blocks/5" -H "Content-Type: application/json" | jq .

Before this MR you should see a Data_encoding error but now you should see the whole block

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR