test(eip7928): add EXTCODECOPY OOG memory expansion BAL test

[qu0b]

Summary

Tests verify that target address should NOT appear in BAL when EXTCODECOPY fails due to OOG at memory expansion

Bug Description

Nethermind's AddAccountRead() is called BEFORE checking gas for memory expansion. When OOG occurs, the account read entry persists in BAL because it's not journaled.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.46%. Comparing base (e927a67) to head (ee3defe).
⚠️ Report is 1 commits behind head on eips/amsterdam/eip-7928.

Additional details and impacted files

@@                   Coverage Diff                    @@
##           eips/amsterdam/eip-7928    #1825   +/-   ##
========================================================
  Coverage                    82.46%   82.46%           
========================================================
  Files                          797      797           
  Lines                        47987    47987           
  Branches                      4341     4341           
========================================================
  Hits                         39574    39574           
  Misses                        7927     7927           
  Partials                       486      486           

Flag	Coverage Δ
unittests	82.46% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 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.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[fselmo]

@qu0b this looks great to me, thanks for adding this!

I added a commit on top of yours that expands on what was already an existing test for extcodecopy with OOG. This leaves the boundary case and the oog_at_cold_access case sort of the same (gas_left = 1) but from different calculations (one has non mem cost but subtracts 1 from total cost so no acct load can happen, the other has mem cost and leaves calculation also with 1 gas less than needed). I am good with this from an implementation check POV since one has mem expansion and one doesn't. Any thoughts before I merge?