test(l2): pin defensive misuse of topics.contains in get_block_l1_messages

[avilagaston9]

Motivation

get_block_l1_messages in crates/l2/common/src/messages.rs
filters logs as

log.address == MESSENGER_ADDRESS
    && log.topics.contains(&L1MESSAGE_EVENT_SELECTOR)

topics.contains(&SELECTOR) returns true if the selector appears
anywhere in the topic list, not specifically at index 0. After
the filter passes, the parser unconditionally reads topics[1]
as from, topics[2] as data_hash, and topics[3] as
message_id — so any log with at least four topics that happens
to contain L1MESSAGE_EVENT_SELECTOR somewhere past index 0 is
parsed as a fake L1Message.

The companion get_block_l2_out_messages already uses the
correct

log.topics.first() == Some(&*L2MESSAGE_EVENT_SELECTOR)

so this is an inconsistency between the two filters in the same
file.

Current reachability

The bug isn't currently reachable through the real EVM emission
path: the only contract whose address matches
MESSENGER_ADDRESS is Messenger.sol, which only emits
L1Message (selector at topics[0]) and L2Message (only 2
topics, so the parser bails out via topics.get(2) == None).
EIP-3541 prevents anyone from deploying new code at
MESSENGER_ADDRESS whose runtime starts with 0xef, but it
doesn't constrain the topic values an event can carry — and
the messenger is upgradeable.

So this is a defensive / latent bug: the day a new event with
three or more indexed parameters is added to the messenger and
one of them carries the L1Message selector value, fake
L1Messages would silently start being parsed. Those would feed
into the committer's l1_out_message_hashes, which is committed
on-chain as the batch's withdrawal merkle root, and the
withdrawal hash for a fabricated message could collide with a
real claim leaf — meaning withdrawals could in principle be
forged via a future event addition. The class is
"a tx that has the wrong leading topic but contains the
selector somewhere" — a known gotcha across multiple Ethereum
clients (e.g. erigon's
ContainsSpecificTopics
discussion), so worth fixing now rather than later.

Description

Adds a regression test
get_block_l1_messages_misparses_log_with_selector_off_topic_zero
in test/tests/l2/l1_messages_filter.rs that feeds a hand-
crafted Log (address = MESSENGER_ADDRESS, topics =
[unrelated, L1MESSAGE_EVENT_SELECTOR, fake_data_hash, fake_message_id]) into get_block_l1_messages and pins the
current (buggy) outcome: the function returns a fabricated
L1Message whose from is the bottom 20 bytes of
L1MESSAGE_EVENT_SELECTOR, data_hash is the third topic,
and message_id is the fourth.

After the fix
(log.topics.first() == Some(&*L1MESSAGE_EVENT_SELECTOR)), the
filter rejects the crafted log and the assertion has to be
updated to messages.len() == 0, prompting an explicit review
of the fix.

The fix itself is intentionally not in this PR — surfacing the
gap and its reproducer first lets the maintainers decide
whether to apply the same first() pattern as
get_block_l2_out_messages or take a different approach (e.g.
also asserting topics.len() >= 4 defensively).

Reproduction

cargo test -p ethrex-test --test ethrex_tests \
  get_block_l1_messages_misparses_log_with_selector_off_topic_zero

The test passes on main (the buggy filter accepts the crafted
log).

Checklist

• Updated STORE_SCHEMA_VERSION (crates/storage/lib.rs) if the PR includes breaking changes to the Store requiring a re-sync.