Cross-circuit check: C1→C5 — verify C5 uses C1 pk_commitments of honest parties

[0xjei]

Ensure the C5 (pk aggregation) proof is built against the actual C1 pk commitments of the parties that passed C1 verification. Today the aggregator filters dishonest parties after C1 and then builds C5 from the honest set; we need an explicit check that the commitments in C5’s inputs (or public signals) match the C1 pk_commitment values of those parties.

Tasks:

• In PublicKeyAggregator (crates/aggregator/src/publickey_aggregator.rs), after C1 verification completes and honest parties are determined:
  • From each honest party’s C1 proof (already available in the VerifyingC1 state), extract the pk_commitment (e.g. second-to-last field in public signals; see tests in zk-prover/tests/local_e2e_tests.rs).
  • When building or validating the C5 proof request/inputs: ensure the list of expected_threshold_pk_commitments passed to C5 matches, in the same order, the C1 pk_commitments of the honest parties.
  • If C5 proof is received from another component (zk-prover): after receiving the signed C5 proof, parse its public signals and compare expected_threshold_pk_commitments (per Issue 1) to the cached C1 pk_commitments; on mismatch, treat as verification failure (and do not publish PublicKeyAggregated or mark appropriately).
• Add a test or assertion that a C5 proof built with a wrong commitment is rejected or the aggregator does not complete.

Acceptance criteria:

• C5 is only accepted when its expected threshold pk commitments match the C1 pk_commitments of the honest parties in the same order.
• No new event types; reuse existing aggregator failure/validation paths.