fix(l1): report status 2 for skipped EIP-8141 frames

[AnkushinDaniil]

Problem

EIP-8141 Receipt Encoding: "A new code 0x2 is introduced for frames which are skipped due to failed atomic batch." The same code is surfaced to the EVM: FRAMEPARAM param = 0x05 "returns 0 for failure, 1 for success, or 2 for a frame skipped due to a failed atomic batch."

ethrex used 0x3 for skipped frames (FRAME_RECEIPT_STATUS_SKIPPED = 3), a value from an earlier draft. That changes the consensus receipt bytes (and therefore the receipt root) of any block containing a frame transaction with a failed atomic batch, and FRAMEPARAM(0x05) returns 3 where a conformant client returns 2.

Change

• FRAME_RECEIPT_STATUS_SKIPPED: 3 -> 2, plus the doc comments and docs/eip-8141.md that repeat the code.
• The receipt RLP round-trip test now pins the consensus bytes of a skipped frame receipt literally ([0xc3, 0x02, 0x80, 0xc0]), so a status regression fails at the encoding layer.
• New end-to-end test: a five-frame transaction where an atomic batch fails asserts the skipped frame's frame_results status is 2 and that FRAMEPARAM(0x05) observed from a later frame reads 2.

Evidence

Commands run on this branch:

cargo check -p ethrex-common                                # pass
cargo check -p ethrex-rpc                                   # pass
cargo check -p ethrex-levm                                  # pass
cargo test -p ethrex-common receipt
# 18 passed; 0 failed; 123 filtered out
cargo test -p ethrex-test --test ethrex_tests levm::eip8141_tests
# 76 passed; 0 failed; 751 filtered out
cargo fmt --all -- --check                                  # pass
git diff --check                                            # pass

Stack

Targets frames-devnet-0. Part of a series of independent EIP-8141 fixes, one PR per logical change, each standing alone against the same base. Siblings: #7040 (canonical low-s), #7043 (recovery id at ecrecover boundary), #7044 (intrinsic gas over payload bytes), #7045 (arbitrary-scheme verification gas), #7046 (frame gas refunds), #7047 (frame receipt storage encoding), #7049 (EIP-7623 calldata floor).

Consensus risk / limits

Consensus-affecting: the skipped-frame status byte is part of the receipt encoding, so it changes receipt roots for blocks with failed atomic batches, and FRAMEPARAM(0x05) results change EVM-visible behavior. Covered by unit and levm end-to-end tests; no cross-client conformance fixture yet.

[edg-l]

Confirmed, and main is the one that's wrong here. Current EIP-8141 specifies 0x2 for frames skipped by a failed atomic batch, in both the receipt section and the TXPARAM status table. Main still uses 3 (see the doc comment on frame_results in vm.rs), a stale spec revision that #7004 did not catch. Good find.