Make prover thread count and aggregated-proof buffer configurable.

[bkolad]

Description

This PR introduces the folloing changes:

1. Add prover_thread_count_override: Option<NonZero<usize>> to ProofManagerConfig. When None (default), prover_thread_count() keeps its previous value of 2 * aggregated_proof_block_jump + 1; when Some(n), the override is used directly.
2. Add max_number_of_aggregated_proofs_in_memory: NonZero<usize> to ProofManagerConfig and thread it through start_zk_workflow_in_background → ZkProofManager. This becomes the capacity of the intake → aggregator mpsc (previously hardcoded to 1),
   so operators can let more completed aggregation windows queue in memory before back-pressure stalls intake.
3. Update the runner's config validation: max_number_of_transitions_in_db & max_number_of_transitions_in_memory
4. Set max_number_of_aggregated_proofs_in_memory = 5 in the example/demo TOMLs and test rollup builders, and bump max_number_of_transitions_in_db/_in_memory accordingly so the new validation passes.

• I have updated CHANGELOG.md with a new entry if my PR makes any breaking changes or fixes a bug. If my PR removes a feature or changes its behavior, I provide help for users on how to migrate to the new behavior.
• I have carefully reviewed all my Cargo.toml changes before opening the PRs. (Are all new dependencies necessary? Is any module dependency leaked into the full-node (hint: it shouldn't)?)

Linked Issues

• Related to [TRACKER]: Implement proof aggregation #2551