Stop the budget walk on settled blocks, and carry its cut out to the response

[mo4islona]

Closes gap 33 in spec/GAPS.md — an S1: wrong results that look right.

The bug

A table whose sort key leads with the block number is scanned in waves that stop
once the budget is crossed. Three things went wrong on that path.

The walk stopped on the wrong weight. It weighed everything it had read, but
part of that belongs to the block the next row group still owns, and that block
cannot be emitted. The blocks that could be emitted were then often lighter
than the budget, so apply_weight_limit never fired.

The stop point went nowhere. scan_budget returned rows only; the boundary
it had computed was dropped. Every other table had been read for the whole
range, so block selection ran past that boundary: the blocks above it came back
carrying the other tables' rows and none of this one's, and lastBlock named the
top of them. A client resuming from lastBlock + 1 never asks for the rows in
between — a 200, with no way to tell.

The wave width reached the answer. A wave is as wide as the rayon pool, so
the same query on the same chunk answered differently at different core counts,
against INV-O13.

There was a fourth, one layer down. The walk trusted the catalog's sort_key.
One archiver wrote statediffs sorted by address while the catalog declares it
block-led, and on that layout the walk drew a boundary out of row groups that
overlap.

The fix

The walk now stops on the weight of settled blocks — those no unread row group
can still add to. That estimate is a lower bound on what apply_weight_limit
charges, so crossing the budget on settled weight guarantees the exact trim lands
at or below the cut. The emitted set is therefore the one a full scan would have
produced, whatever the wave width — which is what closes the determinism half.

scan_budget returns BudgetScan { batches, complete_through }, and
complete_through caps both the header scan and block selection — the same shape
the two-phase pre-scan path already had.

Layout is now read from the row-group statistics rather than the declared sort
key: waves only when the groups' block ranges don't overlap beyond the boundary
block two neighbours share, otherwise a plain full scan, which is what the
reference does on every layout.

Evidence

The query the gap was measured on, run through qdiff against the reference on
the real EVM chunk (stateDiffs with a kind filter, 24550605–24550820):

	before	after
blocks	73	72
lastBlock	24550820	24550676
vs. reference	DIFFER	MATCH

Before, it diverged at 1 and 17 threads and agreed at 2–16. After, it matches at
1, 2, 3, 8 and 17.

A sweep of 12 EVM queries × 4 pool sizes agrees with the reference except for two
cases that also diverge on master — gap 44, the weight model, where this
engine's answer is an exact prefix of the reference's.

Five new tests, each checked by mutating the engine to confirm it fails without
the fix:

• paging_a_partitioned_chunk_loses_no_block — pages a block-partitioned chunk
  end to end at 1, 2 and 17 threads; the concatenation must be the whole chunk
  (INV-B4, INV-B7)
• the_pool_size_does_not_move_a_page_boundary — page boundaries don't move with
  the pool (INV-O13)
• an_overlapping_layout_is_read_whole_rather_than_cut — the address-sorted
  shape falls back to a full scan
• a_wrapped_int32_statistic_draws_no_cut — see the third commit
• a_cut_never_outruns_the_rows_behind_it — complete_through's contract stated
  directly, over every budget and wave width: a block at or below the cut is a
  block the walk read in full

The synthetic chunk needed reshaping to reach the bug at all: the block two row
groups share has to be much heavier than its neighbours, or the exact trim fires
before the cut and nothing is observable. That is why the first version of the
test passed against the broken engine.

Full suite green, including the fixture-gated tests. make fmt, make lint and
make spec-check all pass; INV-B4 and INV-B7 move from P to C, property
coverage 0.71 → 0.73.

Perf-neutral on the one benchmark that takes this path (evm/usdc_traces+diffs,
six interleaved runs a side): 0.995 small, 0.996 big.

Third commit: inverted statistics

Reviewed and confirmed: the new boundary detector could still draw a cut it had
no business drawing.

Widening a stored block number reinterprets the bits, so a signed Int32 past
2³¹ reads back as the block it is. The row group's statistics do not survive
that. A writer comparing the wrapped values signed records the block above the
wrap as the minimum and the highest block below it as the maximum, and widened
back the pair is min > max — a range leaving out most of the blocks the group
holds. Ordering on it puts the group after row groups it precedes, and its
understated maximum clears the overlap check, so the walk would settle blocks
that group has not been read for.

Reproduced on a two-row-group file with a signed Int32 block column: raw
statistics min = -2147483648, max = 2147483647, widened to
min = 2147483648 > max = 2147483647.

The walk now refuses to order a file on such a pair and reads the table whole.

Fourth commit: three more from review

A narrowed integer weighed nothing. The weight model resolved the block
number and the *_size companion through its own downcast chain — four widths
where IntColumn carries eight, which is the duplication src/integers.rs
exists to end. A UInt16 size read as zero, so every row weighed its fixed part
alone and the response the budget was meant to cap went out whole; a UInt16
block number read as absent, so the row belonged to no block and was never
charged at all. Both now resolve through the one list, which also reaches
fork.rs, arrow_out.rs and the exact trim.
a_narrow_size_column_still_reaches_the_budget puts 480 logs of 65 535 bytes
against a 20 MB cap.

The inverted-statistic guard sat behind the reader it was guarding.
select_row_groups prunes on the same widened bounds and runs first, so a group
whose reported range starts above its own end is dropped by any query with a
toBlock below that start — with the rows it holds inside the range, on every
scan path, not just the walk. The pruner now keeps a group it cannot bound.
an_inverted_statistic_does_not_prune_a_row_group_away.

The walk claimed a cut it could not stand behind. retain_blocks_below gives
up on a block number that is null or unreadable, and the weight that crossed the
budget came off that same column — so the stop rested on numbers nothing could
resolve. It reads on instead. Returning no cut and stopping would have been
worse: that is the original bug again.
an_unreadable_block_number_yields_no_cut.

Gap 31's entry gains the fix this argues for: refuse such a chunk with
MalformedChunkData rather than teach four readers about the wrap — with what
refusing gives up, since the rows themselves widen correctly. Also recorded there:
from_block of zero is treated as no lower bound, which is true for an unsigned
column and false for this one.

For review

The sorted_blocks cap and the header_to_block cap are not distinguishable by
mutation under the new stop rule — I checked. They are kept deliberately: they
enforce BudgetScan::complete_through's stated contract, and the stop rule is
what makes them free. The two agree only while the walk's estimate stays under
the exact model, and a block whose header the chunk is missing is already outside
that. Removing them is defensible; it would leave the property resting on an
invariant nothing checks.