Max-cost zkApp transactions failing due to proof verification issues

## Summary Max-cost zkApp transactions are not being created/sent in cluster testing runs due to proof verification failures, surfaced as misleading `Invalid_proof "In progress"` errors. ## Observed behavior - Max-cost zkApp transactions fail to be produced or submitted - Logs show: ``` Batch verification failed when adding from gossip Invalid_proof "In progress" ``` - Other transactions (non-max-cost) appear to work correctly ## Key log signal ```text Batch verification failed when adding from gossip error: Invalid_proof "In progress" ``` ## Expected behavior - Valid max-cost zkApp transactions should be generated and accepted - If proofs are invalid, the system should surface the actual verification error ## Analysis / Hypothesis - Proof verification is likely failing (not actually “in progress”) - Current pipeline: - `verify_commands` returns `Valid_assuming xs` when batch verification fails - Error from `Pickles.Side_loaded.verify` is discarded - Batcher logic: - Treats failed verification as partially valid - Recursively splits batches - Eventually reaches single transaction - Still reports `Invalid_proof "In progress"` This likely masks the real reason max-cost transactions fail. ## Additional context - Recent change introduced max-cost proof caching keyed by zkapp public key - Possible bug in caching logic leading to invalid proofs - Reproduced in cluster testing ## Proposed next steps - Fix error propagation in verifier / batcher path - Investigate proof caching logic - Re-run cluster tests once better error reporting is in place