Implement `Relation` trait for the IVC circuit

## Why

`StmCertificateCircuit` implements the `Relation` trait of the Midnight standard library, while `IvcCircuitData` implements the lower level `Circuit` trait with a hand written configuration. The two circuits therefore produce verifying keys in different formats and the IVC configuration duplicates what `ZkStdLibArch` already provides.

## What

Move the IVC circuit onto `Relation`, so that both circuits share the same configuration mechanism and the same verifying key format. The standard library configures its chips in a different order, so the recursive key identity changes and every asset derived from it is regenerated as part of the move.

## How

- [x] Separate the circuit's metadata from a single step's values, so the metadata type can carry the relation and the values become its witness (`circuits/halo2_ivc/circuit.rs`)
- [x] Move the IVC circuit body from `synthesize` to the `circuit` method of `Relation` (`circuits/halo2_ivc/circuit.rs`)
- [x] Declare the chips through `ZkStdLibArch` and drop the hand written column pool computation (`circuits/halo2_ivc/config.rs`)
- [x] Use `VerifierGadget` from `midnight-zk-stdlib` for the in-circuit certificate proof verification
- [x] Check that the IVC and the certificate verifying keys share the same format
- [x] Relocate the shared verifying key codec so a single implementation serves both circuits (`circuits/key_serialization.rs`)
- [x] Store the recursive proving key together with the relation metadata its circuit is rebuilt from (`circuits/halo2_ivc/key_serialization.rs`)
- [x] Keep the recursive key decoder restricted to the approved architecture, so a verifying key belonging to another circuit is not accepted in its place (`circuits/halo2_ivc/key_serialization.rs`)
- [x] Invalidate the recursive non-production key caches when the recursive key identity changes, leaving the certificate cache identities untouched (`circuits/key_provider.rs`)
- [x] Confirm the recursive circuit still fits its current degree under the standard library configuration, measured with the production certificate metadata, before any key or asset is generated
- [x] Check the impact on the circuit degree and on the golden test vectors, including whether the recursive range column count can be lowered without raising the degree
- [x] Regenerate the production and golden recursive verifying keys and every asset that depends on them, then update the affected digest goldens and the stored combiner challenge

### Jia's explanation
> Simplify configuration of the IVC circuit for Midnight-SK setup:
```rust
fn used_chips(&self) -> ZkStdLibArch {
ZkStdLibArch {
jubjub: true,
poseidon: true,
sha2_256: true,
sha2_512: false,
keccak_256: false,
sha3_256: false,
secp256k1: false,
bls12_381: true,
base64: false,
nr_pow2range_cols: 4,
automaton: false,
blake2b: false,
}
}
```
> Then move the ivc circuit code in `fn synthesize`  to `fn circuit` from `Relation` .
> If we do this, both ivc_vk and cert_vk will have the same format `MidnightVK`
> `VerifierGadget` is available here https://github.com/midnightntwrk/midnight-zk/blob/main/zk_stdlib/src/lib.rs#L847
> it is also available in `midnight-zk-stdlib = { version = "2.3.0" }`
> Then move the ivc circuit code in `fn synthesize`  to `fn circuit` from `Relation` .
> If we do this, both ivc_vk and cert_vk will have the same format `MidnightVK`
> `VerifierGadget` is available here https://github.com/midnightntwrk/midnight-zk/blob/main/zk_stdlib/src/lib.rs#L847
> it is also available in `midnight-zk-stdlib = { version = "2.3.0" }`