feat(zk-backend): two-stage groth16 dry-run

[mw2000]

Summary

• Extend the dry-run backend to advance SnarkGroth16 jobs from the STARK range stage to a SNARK aggregation stage via submit_next, storing a per-stage result keyed by backend session id.
• Lets the host orchestrator (introduced in the base PR) exercise the full composed range-to-aggregation flow locally without a real proving backend.

Made with Cursor

[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]

Review Summary

PR: feat(zk-backend): two-stage groth16 dry-run

This PR extends the dry-run ZK backend to support the two-stage STARK-to-SNARK flow via submit_next. The implementation is clean and well-tested.

What looks good

• Atomicity: advance_range_to_snark correctly holds a single Mutex lock across the entire check-remove-insert sequence, preventing any TOCTOU window.
• Idempotency: The early return when backend_session_id already exists in the store satisfies the ZkProver::submit_next idempotency contract documented on the trait.
• Naming: The DRY_RUN_PREFIX → DRY_RUN_STARK_PREFIX rename with a new DRY_RUN_SNARK_PREFIX is clean and complete — no stale references remain in the codebase.
• Testability: Extracting advance_range_to_snark as a static method taking &Mutex<...> rather than &self allows unit tests to exercise the logic without constructing a full DryRunZkProver. Good design.
• Test coverage: Both the happy-path swap and the idempotent-resume case are covered.

No new issues found

The existing inline comments from the prior review round have been addressed in the current code. No additional concerns to raise.