ci: run execution spec tests

[Qumeric]

Run the pinned tests-zkevm@v0.4.1 execution-spec suite on every pull request and on demand.

Key decisions:

• Run on every PR instead of a cron because the cached job completes in roughly three minutes and catches regressions before merge.
• Pin the fixture release and checksum, and fail if the standalone test lockfile drifts from the workspace OpenVM revision.
• Treat the current Reth divergences as an exact baseline: both new failures and unexpectedly resolved divergences fail the test.
• Use host k256 implementations in native CI because OpenVM k256 relies on guest-only intrinsics; preserve the existing guest recovery paths because sharing them through a helper regressed metered guest instructions.

---

Closes INT-8714

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	cargo/​serde_json@​1.0.150
	cargo/​rayon@​1.12.0

View full report

[socket-security]

Warning

Review the following alerts detected in dependencies.

According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.

Action	Severity	Alert  (click "▶" to expand/collapse)
Warn		Obfuscated code: cargo writeable is 90.0% likely obfuscated Confidence: 0.90 Location: Package overview From: ? → cargo/writeable@0.6.3 ℹ Read more on: This package | This alert | What is obfuscated code? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: Packages should not obfuscate their code. Consider not using packages with obfuscated code. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore cargo/writeable@0.6.3. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		Obfuscated code: cargo zerocopy is 90.0% likely obfuscated Confidence: 0.90 Location: Package overview From: ? → cargo/alloy-eips@1.5.2 → cargo/alloy-trie@0.9.4 → cargo/reqwest@0.13.3 → cargo/metrics@0.24.6 → cargo/alloy-primitives@1.6.0 → cargo/alloy-json-rpc@2.0.5 → cargo/alloy-rpc-types@2.0.5 → cargo/alloy-eips@2.0.5 → cargo/alloy-rpc-client@2.0.5 → cargo/alloy-consensus@2.0.5 → cargo/alloy-provider@2.0.5 → cargo/alloy@2.0.5 → cargo/revm@40.0.3 → cargo/reth-primitives-traits@0.4.1 → cargo/reqwest@0.12.20 → cargo/ark-bls12-381@0.5.0 → cargo/ark-bn254@0.5.0 → cargo/ark-ec@0.5.0 → cargo/ark-ff@0.5.0 → cargo/aurora-engine-modexp@1.2.0 → cargo/alloy-trie@0.8.1 → cargo/metrics@0.23.1 → cargo/revm@27.1.0 → cargo/bls12_381@0.8.0 → cargo/actix-web@4.12.1 → cargo/zerocopy@0.8.54 ℹ Read more on: This package | This alert | What is obfuscated code? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: Packages should not obfuscate their code. Consider not using packages with obfuscated code. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore cargo/zerocopy@0.8.54. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.

View full report

[shuklaayush]

nice! this should be really useful
one suggestion is to adopt a custom test harness like datatest-stable so individual fixtures appear as separate test cases. not sure if it's possible here but worth a try

[Qumeric]

dataset-stable is a good suggestion but I don't think it's a fit for a huge amount of very small test -- it starts a separate nextest process for each test. We can do custom test harness but it seems like an overkill, so I would keep it as it is