chore(zk-host): orchestrate groth16 aggregation

[mw2000]

Summary

ZK host now treats SnarkGroth16 jobs as a composed range-to-aggregation flow: it records the initial STARK range session, lets backends advance to a SNARK aggregation session, and resumes from the recorded SNARK session so prover-service continues handling a single generic proof request.

[cb-heimdall]

🟡 Heimdall Review Status

Requirement	Status	More Info
Reviews	🟡 0/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 2 if repo is sensitive 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 1 Sum 2

[github-actions]

Stale comment: this says "Reuse the configured proof limits for both range and aggregation stages" but the aggregation request (line 856-857) now correctly uses aggregation_cycle_limit / aggregation_gas_limit. This comment should be removed or updated to just say these are the range-specific limits.

Suggested change

	// Reuse the configured proof limits for both range and aggregation stages.
	cycle_limit: self.config.range_cycle_limit,
	gas_limit: self.config.range_gas_limit,
	cycle_limit: self.config.range_cycle_limit,
	gas_limit: self.config.range_gas_limit,

[github-actions]

session_type is ignored here, and download() unconditionally returns ProofResult::Compressed. The cluster, mock, and dry-run backends all dispatch on session_type to return the correct ProofResult variant. While the network backend currently blocks Groth16 at submit(), this will silently return the wrong proof type if Groth16 support is added without updating download(). Consider either adding the same session_type check, or asserting session_type == Stark to fail loudly.

[github-actions]

Review Summary

The PR introduces a well-structured two-stage Groth16 aggregation flow: STARK range proof → SNARK aggregation. The orchestration in proof_generator.rs is clean — the wait_for_backend_session loop records the STARK completion, calls submit_next for aggregation, records the SNARK session, and continues polling. The resume logic in resume_backend_session correctly handles crash recovery by checking the SNARK session first, then falling back to the STARK session (which, if already Completed, re-drives only the aggregation via submit_next).

Findings

Minor (2 inline comments posted):

1. Stale comment in cluster.rs:671 — says "Reuse the configured proof limits for both range and aggregation stages" but the aggregation request now has its own dedicated aggregation_cycle_limit/aggregation_gas_limit. The comment is misleading and should be removed.

2. Network backend download() ignores session_type (network.rs:400) — always returns ProofResult::Compressed regardless of session_type, unlike the cluster/mock/dry-run backends which dispatch on it. Safe today since network blocks Groth16 at submit(), but will silently produce wrong results when Groth16 support is added.

Note on prior review comments

Most of the 13 existing inline comments from the previous review run are stale and refer to code patterns that no longer exist in the current iteration (e.g., MOCK_SNARK_PREFIX dead code — already removed; SP1PublicValues::read() panic — replaced with proper bincode::serde::decode_from_slice error handling; network submit_next concerns — network doesn't implement submit_next; STARK session not recorded as Completed — now recorded at proof_generator.rs:354-361).

[github-actions]

✅ base-std fork tests: all 616 passed

base/base is fully in sync with the base-std spec.

Dependency	Ref	Commit
base-std	main	4658f1b7
base-anvil	0092692587d8d064dd2c6923ce26a682c58f3694	00926925