[M-1] Unbounded deserialization allows memory exhaustion DoS

**Context**: `crates/zk-core/src/store.rs`

### Description

`ProverFlush` is `Deserialize`d from untrusted input and contains potentially large `FlushView` (a `RangeSet`) plus `BitVec` fields (`adjust` and optional MAC proof bits).
The `TryFrom` validation only checks internal length consistency (commit bits == `adjust.len()` and prove bits == MAC proof bits), but does not enforce any upper bound on the amount of data that can be allocated during deserialization.

A malicious peer can send an oversized serialized `ProverFlush` to trigger large allocations (and subsequent processing), causing OOM or severe CPU/memory pressure before the verifier can reject it (e.g., even if `VerifierStore::receive_flush` later detects a `view` mismatch).

**Impacted code**
```rust
#[derive(Debug, Serialize, Deserialize)]
#[serde(try_from = "validation::ProverFlushUnchecked")]
pub struct ProverFlush {
view: FlushView,
adjust: BitVec,
mac_proof: Option<(BitVec, Hash)>,
}

impl TryFrom for ProverFlush {
type Error = String;

fn try_from(value: ProverFlushUnchecked) -> Result {
let ProverFlushUnchecked { view, adjust, mac_proof } = value;

if view.commit.len() != adjust.len() {
return Err("prover sent flush with invalid number of adjustment bits".to_string());
}

let mac_proof_bits = match mac_proof {
Some(ref proof) => proof.0.len(),
None => 0,
};

if view.prove.len() != mac_proof_bits {
return Err("prover sent flush with invalid number of mac proof bits".to_string());
}

Ok(ProverFlush { view, adjust, mac_proof })
}
}
```

### Recommendation

Enforce strict maximum sizes at the deserialization boundary (e.g., message/frame size limits, bincode/serde size limits) and/or add explicit caps in `TryFrom` (maximum total committed/proved bits and maximum number of ranges in `FlushView`) derived from protocol/circuit limits.

Consider avoiding serializing `view` entirely if both parties can derive it locally, or validate sizes before allocating (custom deserializer/visitor).

Start in crates/zk-core/src/store.rs by reading ProverFlush deserialization, validation::ProverFlushUnchecked, and VerifierStore::receive_flush. Trace when FlushView, adjust, and mac_proof are allocated and identify the protocol or circuit limits available for validation. Done means oversized serialized input is rejected at or before deserialization, with bounds covering the relevant bits and ranges.

Written by the indexing model from the issue text.