refactor(test-evm-tools): derive fork-block activation from the transition schedule

[spencer-tb]

Description

Replace the fork_activation flag with the transition schedule. The filler hands the t8n the transition fork instead of the per-block resolution; the in-process EELS t8n resolves the block's side of the boundary itself and, when that side has fork-block logic (is_fork_block in its fork module), runs it with the transition's activation criteria via the existing ForkCache override, so the spec's own predicate decides whether the EIP-8253 bump applies. ethereum-spec-evm t8n accepts transition names such as BPO2ToAmsterdamAtTime15k for the same purpose. Legacy aliases (HomesteadToDaoAt5) keep their find_fork path.

External tools are unchanged: they still receive the resolved per-block fork name and no activation information, checked by driving a geth-classified wrapper through a transition test (--state.fork=BPO2, then =Amsterdam).

Fixtures are identical to the flag version, ignoring _info: the EIP-8253 directory (154 cases on this base) and the 7928, 7997, 8037, 8282 and 4844 transition tests (241 cases). Cloning a fork with overridden criteria costs about six seconds once per worker, only for forks with fork-block logic.

Related Issues or PRs

Framework follow-up to ethereum#3535; independent of #7.

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.

[spencer-tb]

Superseded by ethereum#3557, the same change on forks/amsterdam without the EIP-8253 pieces, so ethereum#3535 can rebase onto it.