feat(forks): let development forks inherit exact-fork validity

[CPerezz]

Description

Filling against a development fork silently dropped every test pinned with valid_at: the marker resolves to literally the named forks, so BinaryTree — which subclasses Amsterdam and is selected by valid_from — never intersected, and the tests were simply not parametrized. This PR makes those tests fill rather than merely reporting them as dropped (an earlier revision of this PR implemented reporting only; it was reverted in favor of inclusion).

• A fork can now be declared with inherits_exact_fork_validity=True (new BaseFork.__init_subclass__ class argument + accessor), meaning it keeps its parent's execution semantics, so tests pinned to the parent remain meaningful for it.
• ValidAt expands each fork it resolves — named directly or via an EIP name — onto declaring subclass forks, transitively (expand_forks_with_inherited_validity).
• BinaryTree declares it, so the 14 Amsterdam-pinned valid_at usages fill under --fork BinaryTree with zero test-file edits, and the next development fork is a one-line declaration.

The expansion is deliberately opt-in per fork rather than automatic subclass widening (the issue's option 3): unconditional widening would silently pull BPO forks into every valid_at("Osaka")-family fill, conflicting with the deliberate valid_for_bpo_forks opt-in. Tests pinned to non-ancestor forks (e.g. valid_at("Prague")) and valid_at_transition_to(...) tests remain excluded — no transition fork to BinaryTree exists.

Verified end-to-end: just binary-trie-fork tests/amsterdam/eip7981_increase_access_list_cost now fills 357 fixtures including the previously-dropped valid_at tests (e.g. test_access_list_token_calculation[fork_BinaryTree-...]); before this change the directory filled only its valid_from tests.

Tests: adds the first pytester coverage for plain valid_at (it previously had none — every valid_at* case was valid_at_transition_to), covering the positive case, parent inheritance, EIP-name resolution onto the inheriting fork, and non-ancestor exclusion.

Related Issues or PRs

Fixes #3260.

Checklist

• Ran fast static checks to avoid CI fails, see Code Standards & Verifying Changes: just static
• PR title has the form <type>(<area>): <title>, where <type> and <area> come from an appropriate C-<type>, respectively A-<area>, label. The title should match the target squash commit message.

Cute Animal Picture

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.01%. Comparing base (0834495) to head (d7ca47b).

Additional details and impacted files

@@                   Coverage Diff                    @@
##           projects/binary-trie    #3289      +/-   ##
========================================================
- Coverage                 93.01%   93.01%   -0.01%     
========================================================
  Files                       628      628              
  Lines                     37383    37376       -7     
  Branches                   3442     3435       -7     
========================================================
- Hits                      34773    34766       -7     
  Misses                     1854     1854              
  Partials                    756      756              

Flag	Coverage Δ
unittests	93.01% <ø> (-0.01%)	⬇️

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

☔ 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.

[CPerezz]

Waiting to be properly fixed after #3279

[kevaundray]

Can you clarify what this is meant to be fixing?

To me, the valid_at syntax is correctly only activating a test at a particular fork, and future forks whether development or real wouldn't need those tests activated.

It's unclear to me, if we want to be able to test binary tries at something that can only happen in prague for example, because such a scenario is not going to happen.

[marioevz]

Do you have some examples of tests that you need to run on the binary fork that are constrained by the valid_at("amsterdam") marker? Perhaps an alternative would be to give them the valid_from("amsterdam") marker instead, but not sure.

[CPerezz]

@marioevz concrete case: tests/amsterdam/eip7981_increase_access_list_cost. All 5 modules there are valid_at/valid_at_transition_to-pinned but not a single valid_from test in the dir, so under --fork BinaryTree the whole EIP silently disappears.

If you'd still rather not touch ValidAt, I can re-mark 7981 and drop this — but next dev fork hits the same wall, that's what I'm trying to kill. Could also exclude mainnet-tagged tests from the expansion if the smokes are the concern.

[kevaundray]

Hmm I still fail to understand why the solution is not to just change specific tests to be valid_from so they run from that fork onwards, and or add more tests that are marked valid_from

valid_at in general, seems like a reasonable marker to have if you only want to test something at that specific fork. For example, testing that before some fork, the gas price was X and after it increased to Y; ie the clients correctly increased the correct constants

[CPerezz]

Sure @kevaundray fine with that. Not really married to anything here. Shall we just close this then?

[kevaundray]

Yeah unless I'm missing something, I would close and maybe look for tests that we can change from valid_at to valid_from