fix(evm): load L1 block info at block 0 on release-v1.7.2

[mega-putin]

Summary

Cherry-pick 17ca265bcf97f8f998c71a5123cfb09979bae270 (fix(evm): load L1 block info for transactions at block 0, mega-evm #392) onto release-v1.7.2 after the candidate bump (#396).

Main already has this. The 1.7.2 line did not.

Replaces closed #395, which targeted the pre-force-update release-v1.7.2 tip.

factory.rs conflicted because 1.7.2's tests module is not the same as main. Resolution:

• Production change is the same as fix(evm): load L1 block info for transactions at block 0 #392: mark L1BlockInfo.l2_block = U256::MAX so block 0 reloads L1 info from state.
• Keep the 1.7.2-only test_external_env_factory_getter.
• Bring over test_non_deposit_tx_at_block_zero_loads_l1_block_info_from_state.
• Do not bring main's test_dyn_precompiles_builder_receives_the_behavior_spec (not on this line).

Test plan

• CI on this PR against release-v1.7.2
• Confirm only crates/mega-evm/src/evm/factory.rs changed besides cherry-pick metadata

[mega-maxwell]

Claude review status

Living comment — rewritten in place. The review workflow keeps this single comment up to date instead of posting a new one each round, so it always describes the latest reviewed commit and the earlier text is intentionally gone. No reply is needed here; reply to a finding in its own review thread, and answer an open question in a reply on this PR. The next review round reconciles your answer.

✅ Review clean

Last reviewed: head fe51a480 · updated 2026-09-30T02:57:36+00:00

New this round: 0 finding(s), 0 question(s) · Resolved this round: 0 · Open questions: 0

[github-actions]

🧬 Mutation testing — ✅ PASS

Nothing to test — no mutants were generated on the changed lines.

[mega-putin]

Done, agreed with the rationale here.

I replaced spec:stable with spec:unchanged; the current labels are now comp:core, spec:unchanged, and api:unchanged.
The require-label triage job is passing with that label set.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.3%. Comparing base (a08ccfa) to head (fe51a48).

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[github-actions]

🧬 Mutation testing — ✅ PASS

Nothing to test — no mutants were generated (1 unviable, 0 timed out).

[mega-putin]

🔧 Pushed CI fixes.

Agent log

Created an empty CI-refresh commit:

`fe51a48 fix CI: refresh checks after label triage`

What I found:

- Job-level check inspection showed the only failed check on the old PR head was the stale `require-label` run from before labels were fixed.
- Current labels pass the triage script locally: `comp:core`, `spec:unchanged`, `api:unchanged`.
- The actual code CI jobs (`lint`, `test`, `no-std`) were already passing at job level.
- I tried to rerun the stale failed workflow, but GitHub rejected it with `Resource not accessible by integration`.

No code changed, so there were no formatter/linter/test changes to make. I did not push.

[mega-putin]

Thanks, both reports are green.

Codecov shows all modified coverable lines covered, and mutation testing reports no generated mutants, so there is no follow-up change needed here.

[codspeed]

Merging this PR will degrade performance by 9.53%

⚠️ 16 benchmarks measured no execution time

Nothing ran under measurement, usually because the compiler removed the code under test. These results are not comparable, so they count as unchanged.

Preventing compiler optimizations

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

❌ 5 regressed benchmarks
✅ 347 untouched benchmarks
⏩ 33 skipped benchmarks¹
🗄️ 44 archived benchmarks run²

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Benchmark	BASE	HEAD	Efficiency
❌	rex4/1_txs	217.6 µs	246.6 µs	-11.78%
❌	rex4/deploy_1	227.1 µs	256 µs	-11.29%
❌	mini_rex/5_mixed_txs	496.7 µs	543 µs	-8.54%
❌	equivalence/5_mixed_txs	609 µs	664.3 µs	-8.33%
❌	rex4/1_txs	317.3 µs	343.4 µs	-7.62%
⚠️	estimated_da_size[0]	< 1 ns	< 1 ns	N/A
⚠️	estimated_da_size[1000]	< 1 ns	< 1 ns	N/A
⚠️	estimated_da_size[180]	< 1 ns	< 1 ns	N/A
⚠️	estimated_da_size[68]	< 1 ns	< 1 ns	N/A
⚠️	tx_size[0]	< 1 ns	< 1 ns	N/A
⚠️	tx_size[1000]	< 1 ns	< 1 ns	N/A
⚠️	tx_size[180]	< 1 ns	< 1 ns	N/A
⚠️	tx_size[68]	< 1 ns	< 1 ns	N/A
⚠️	estimated_da_size[0]	< 1 ns	< 1 ns	N/A
⚠️	estimated_da_size[1000]	< 1 ns	< 1 ns	N/A
⚠️	estimated_da_size[180]	< 1 ns	< 1 ns	N/A
⚠️	estimated_da_size[68]	< 1 ns	< 1 ns	N/A
⚠️	tx_size[0]	< 1 ns	< 1 ns	N/A
⚠️	tx_size[1000]	< 1 ns	< 1 ns	N/A
⚠️	tx_size[180]	< 1 ns	< 1 ns	N/A
...	...	...	...	...

ℹ️ Only the first 20 benchmarks are displayed. Go to the app to view all benchmarks.

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing mega-putin/cherry-pick/l1-block0-1.7.2-post396 (fe51a48) with main (17ca265)³}

Footnotes

1. 33 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

2. 44 benchmarks were run, but are now archived. If they were deleted in another branch, consider rebasing to remove them from the report. Instead if they were added back, click here to restore them. ↩

3. No successful run was found on release-v1.7.2 (a08ccfa) during the generation of this report, so main (17ca265) was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[mega-putin]

❓ CodSpeed is failing because it compared this release-v1.7.2 PR against main due to a missing release-v1.7.2 baseline; should this be handled by someone with permissions acknowledging/dispatching the correct CodSpeed baseline, or do you want a workflow-policy change in this PR?

(I've paused on this task. Reply here with the answer and I'll continue where I left off.)