Derive page configs without a per-byte image

[jotabulacios]

Motivation

page_configs_from_elf answers one question — which memory pages the program
starts with, and what is in them — and it answered it by building a
HashMap<u64, u8> with one entry per byte of the ELF, then grouping those
bytes into pages, then cloning each page's data. With ethrex.elf that is
about four million SipHash inserts to reorganize data the segments already
hold in order.

The verifier runs this: it does not receive the initial memory image in the
proof, it reconstructs it from the ELF to check the PAGE table's
preprocessed columns. And the recursion guest runs the verifier, where every
instruction is a trace row someone has to prove. On the ethrex mainnet block
it was 50.5% of the batched guest's cycles.

It is not specific to prove-and-retire: the monolithic verifier
(prover/src/lib.rs) reaches it through the same
page_configs_from_elf_and_runtime, so the proof main emits today pays it
too.

Description

Write straight into the page instead. For each segment, compute how many words
fit in the current page, look that page up once, and copy the run with
copy_from_slice — one lookup per page-run rather than one per byte. A
segment whose base is not 4-aligned keeps the byte path, because a word can
then straddle a page boundary. into_iter() moves each Vec<u8> into its
PageConfig, so the final clone is gone as well.

The result has to be identical, not equivalent — this is a verifier path.
Ascending bases (BTreeMap iterates sorted, as the BTreeSet did), last
write wins inside a segment run, and partial pages zero-filled. The
else { zero_init(base) } arm that disappears was dead: page_bases came
from init_page_data.keys(). build_initial_image itself stays — six other
callers use it.

page_configs_match_the_byte_image_derivation runs both derivations over the
Rust ELF artifacts and compares page count, bases and init values.

Results

Recursion guest cycles on the ethrex mainnet block (blowup 2, 219 queries),
measured on vm-benchmarks-1 with the same input blob on both sides:

guest	before	after	Δ
batched (this branch)	5,312,777,458	2,700,213,321	−49.2%
monolithic (what main emits)	6,659,026,733	3,372,246,504 (¹)	−49.4%

Keccak call counts are identical on both sides — 3,963,993 batched,
11,803,481 monolithic — so the two runs do the same work and only the path to
it changed. Native verification moves little: the derivation is a small share
of a 6 s host verify.

(¹) The monolithic figure is from a run that also carried the keccak-state fix
(#1000); that fix is worth 8.2% of the batched guest, so essentially all of
this delta is the page derivation.

For the batched path the ordering changes with it: without this fix the
batched guest costs 5.31 G against continuations' 4.65 G, and with it 2.70 G —
42% below continuations instead of 14% above.

How to test

cargo test --release -p lambda-vm-prover page_configs_match_the_byte_image_derivation

Needs the Rust ELF artifacts (make compile-programs-rust); the test skips
any it cannot read and fails if it found none.