Fix/chunk test suite stale num pubs

[yeziR4]

Summary

cargo test -p bitvm --release chunk:: on this branch currently fails to compile before any test runs:

error[E0425]: cannot find function `generate_segments_using_mock_vk_and_mock_proof` in this scope
    --> bitvm/src/chunk/api.rs:1477:25

generate_segments_using_mock_vk_and_mock_proof was moved to api_compiletime_utils in an earlier refactor; the #[cfg(test)] mod test in chunk/api.rs was never updated to import it from its new location. This one-line fix restores the import and unblocks compilation.

What this uncovers (not fixed in this PR)

With the import restored, the suite compiles and 7 tests fail:

chunk::api::test::full_e2e_execution
chunk::api::test::test_largest_chunks
chunk::api_runtime_utils::test::test_runtime_execution_looped
chunk::g16_runner_core::test::test_groth16
chunk::g16_runner_core::test::test_verify_pairing
chunk::taps_msm::test::test_tap_msm_invalid_inputs_scalar_not_fr
chunk::taps_msm::test::test_tap_msm_valid_inputs

All 7 trace to the same root cause: a hardcoded test fixture (vk_bytes / proof_bytes / a single scalar) shared across five test functions was built from a verifying key with 1 public input. NUM_PUBS (bitvm/src/chunk/api.rs) has been 2 since the merge-conflict-resolution commit 7b31dfd (Nov 21, 2025) — roughly 9 months. Representative panics:

thread 'chunk::g16_runner_core::test::test_verify_pairing' panicked at bitvm/src/chunk/g16_runner_core.rs:1128:25:
index out of bounds: the len is 1 but the index is 1

thread 'chunk::api::test::full_e2e_execution' panicked at bitvm/src/chunk/api_compiletime_utils.rs:44:5:
assertion failed: vk.gamma_abc_g1.len() == NUM_PUBS + 1

I don't believe this is exploitable in production — goat::disprove_scripts::test_verify_guest_pubin_ziren, which deserializes a real 2-element public-input array from ziren/public_inputs.bin, passes cleanly, so the live Ziren integration matches NUM_PUBS = 2 correctly. This also isn't the Zellic-audited MSM finding (3.19, commit 9f2a42a) — that was a Script stack-drop bug in taps_msm.rs with no test-fixture changes; this is a separate, distinct gap.

The real-world impact is coverage risk: the regression suite for the chunked Groth16 pairing verifier — the code that ultimately decides whether a cheating operator gets caught on-chain — has evidently not produced a passing cargo test -p bitvm run in ~9 months, meaning a genuine regression introduced anywhere in chunk:: during that window would not have been caught.

This PR intentionally fixes only the compile break. Regenerating the shared fixture with a real 2-public-input proof (or parameterizing the affected tests to read NUM_PUBS from the VK's own gamma_abc_g1.len() - 1 instead of assuming a constant) needs a decision from the team on the right fixture/approach, so I've filed that separately rather than guessing at a replacement proof.

Testing

cd bitvm && cargo test -p bitvm --release chunk::

Before: compile error. After this PR: compiles, 35 passed; 7 failed; 8 ignored (see above — expected given the stale fixture).