test(lfm): gate the per-table epoch-verifier wrap on every suite run

[MauroToscano]

The gap

The only NON-ignored epoch-verifier wrap prove test was the_fixture_epoch_wraps_batched, and its inner epoch is batched. All four per-table equivalents are #[ignore]d for cost: the_wrap_proves_and_verifies, the_real_block_epoch_wraps, the_from_proof_final_epoch_wraps, the_real_block_proves_and_wraps_end_to_end.

So the per-table proof FORMAT was covered — the leg suites prove it, and the batched wrap's own proof goes through lfm_prove — but the per-table epoch verifier PROGRAM was never proved on a suite run, only executed. By the method's rule 2 an execute-only test says nothing about the chips: where the executor mirrors a computation the chip also does, only a prove+verify run sees the chip.

With the batched format being deleted, that arm would have become the untested one. This is the per-table twin that keeps it from being.

What it does

the_fixture_epoch_wraps, not ignored: the min-preset fibonacci fixture epoch, epoch_program with legs, build_artifacts_with_hasher(.., BLOCK_HASHER), lfm_prove, verify_against, the epoch's own published oracles checked by value, and two falsification arms.

Two arms, not one check twice. A flipped main root makes the wrap UNBUILDABLE and never reaches the verifier, so it says nothing about verify_against's reject path. The second arm hands the verifier the real proof under a moved claimed word, which absorb_lfm_statement binds against, and asserts rejection. One shows the machine will not lie; the other shows the verifier catches a lie. About 0.16s of the 9.2s.

wrap_run_from's third arm, the moved PROGRAM DIGEST, is the registry premise rather than this program's, and machine_tests::verify_against_artifacts_agrees_with_the_registry_path (machine_tests.rs:5403) already holds it on a trivial program.

It takes EpochInputs::fixture() rather than from_env(), exactly as the batched twin does, so a measurement run's LFM_CENSUS_* variables cannot turn a suite gate into a real-block run.

The pin, named rather than implied

epoch_program builds at WrapHash::production(). Under an algebraic pin that lowers the emitter's Merkle work to Instr::Hash and consults the LFM_HASH socket, so this site is in the class that must be proved under BLOCK_HASHER. It names the pin twice over: build_artifacts_with_hasher for the artifacts and lfm_cell_counts_with_hasher for the numbers, so neither the proof nor the census can be taken at HasherKind::default().

The rule is quoted inline in the test doc rather than cited: the document carrying it lands with the RPX pin and does not exist on this branch, so a citation would dangle. A program built at WrapHash::production() emits Instr::Hash and must be proved under BLOCK_HASHER. A program that pins a byte hash on its own builder emits none, never consults the socket, and is correct at the registry's blessed default under every pin.

On a byte pin that naming is inert, and that is the trap: ByteWrapHash emits no Instr::Hash at all, so a defaulted socket hasher is free and correct here and becomes wrong only when the pin moves. Written pinned now so the flip is not a bug-hunt later, which is what it was at f6ca405c and again for fri_tests / join_tests at v10.

The gate therefore runs unchanged when the RPX pin PR lands: the test reads the pin.

Why the allowlist took no new file

prover/src/tests/hash_pin_enumeration.rs is a blessed-set scan over files that MENTION an implied-hash symbol. This site mentions none, so blessing lfm/wrap_tests.rs would fire the gate's own stale assertion and break it.

The registration is instead an amended reason on the existing lfm/airs.rs entry, naming the new pinned consumer and recording why it must not be simplified back to the defaulting census pair: the LFM_HASH chip's width is tenant-dependent, so a defaulted census under an algebraic pin reports the WRONG chip rather than a smaller number. That is the pin branch's own lesson — "test-only" is not "safe", it is only "production-safe" — applied to a site that now proves against pinned artifacts on every suite run.

Evidence

Box A, commit b7995d53, verbatim:

inner epoch: fibonacci fixture, 2^3 cycles, 8 cycles executed, 25 sub-proofs, proved in 3.1s
★ THE PER-TABLE WRAPPED PROGRAM
   210782 instructions / 1 keccak permutations / 16461 arena words / 1 chunks
   census at Test: 42096912 main + 13320972 aux ext = 82059828 base-field equivalents; PROJECTED peak RSS 2.6 GiB (a projection from slice 0's coefficient, not a measurement of this run)
★ PER-TABLE WRAP PROVED AND VERIFIED (inner epoch [2 x18, 3, 4 x2, 5 x2, 7, 20], blowup 2, 1 query)
   prove 3.8s / verify 0.16s / proof 45953352 bytes / 168 published words / 15 sub-proofs
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 1163 filtered out; finished in 9.20s

test tests::hash_pin_enumeration::no_call_site_outside_the_pin_reaches_a_default_alias ... ok
test result: ok. 1 passed

make lint, box A: exit 0 over all six passes at b7995d53, and again at b5ad16ff. Re-running at the pushed head fee4e770.

The shape, and the wall

shape	min preset, blowup 2 at one query, fibonacci fixture epoch, 25 inner sub-proofs, every leg
program	210,782 instructions, 16,461 arena words
census at the pin	42,096,912 main + 13,320,972 aux ext = 82,059,828 base-field equivalents
wall	9.20s on box A. CI expectation 30-60s on a 2-4 vCPU runner under --test-threads=1, ? INFERRED
wrap proof	45,953,352 bytes over 15 wrap sub-proofs

Memory and time are separate verdicts and are not averaged. Peak RSS was not measured on this run; the 2.6 GiB the test prints is a projection from an existing coefficient and is labelled as one in the output.

The min preset is the floor on the preset axis: MIN_PROOF_OPTIONS is already blowup 2 at one query, and the leg set is the epoch's own sub-proof count rather than a choice. A knob to trade the WRAP proof's own query count for wall time was written and then removed once the shape was measured — at 9.2s there is nothing to buy, and a dormant setting that quietly weakens a suite gate is worse than no setting.

The 46 MB proof is the framework query count over 15 wrap sub-proofs, not anything about the inner epoch. It is fine for a gate that builds, verifies and drops it in-process.

Two things deliberately NOT done

Slice 0's numbers are annotated, not corrected (35c00aa6, after review). An earlier revision of this PR claimed the ~2.25M figure "was recorded against a different shape". That was wrong and is retracted: wrap_run passes EpochInputs::from_env, which with no LFM_CENSUS_* set is byte-for-byte EpochInputs::fixture, so in a clean environment slice 0 and the new gate are the same program built from the same epoch. One program carrying two figures an order of magnitude apart is the finding.

The ⚠ therefore sits on slice 0's signature and on MEASURED_BYTES_PER_CELL's provenance line, where the doubtful numbers live, rather than on the new test. An LFM_CENSUS_*-overridden run is named as the likely explanation and marked as a hypothesis; "the shape shrank since" is not excluded. Neither value is changed. The coefficient especially: a ratio of two numbers taken together on one run stays valid whichever shape that run was, and re-deriving it from a shape whose RSS nobody measured would swap a misfiled observation for a fabricated one. What it needs is one --ignored run of slice 0 in a clean environment, after which all three move together or none do. The measured figure for THIS test is recorded in its own doc so the stale one stops circulating for this shape.

epoch_verify_tests.rs:505 is left alone. the_assembled_epoch_verifier_runs is non-ignored and executes a program built at WrapHash::production() under a literal TestPermutation rather than BLOCK_HASHER — the same class this PR closes, and tracked as a separate follow-up.

Not run here

The RPX pin. per-table-gpu is cut from the unpinned base, so the branch default is the BLAKE3 control and there is no RPX pin to run against yet. The pin lands as its own PR; this gate needs no change when it does.