Centralize protocol constants and enforce cross-layer drift checks

[0xjei]

Problem

Protocol constants are still maintained in several independent files. This creates drift risk across Rust, Noir, TypeScript, generated Solidity, and deployment/test fixtures.

The current BFV values already disagree:

• crates/fhe-params/src/constants.rs defines the secure threshold plaintext modulus as 1000000 and uses 0x020... moduli.
• The generated secure Noir config contains the same 1000000 and 0x020... values.
• packages/interfold-contracts/scripts/protocol/constants.ts and packages/interfold-contracts/scripts/deployInterfold.ts define 131072 and different 0x040... moduli.
• scripts/build-circuits.ts imports the TypeScript values and uses them to generate ActiveCryptoConfig.sol, so the generated on-chain configuration follows a different source from Rust and Noir.

The deployment comment claims that its values come from crates/fhe-params/src/constants.rs, which is not true for the secure preset.

Scope

• Define ownership for protocol parameters, committee sizes, circuit bounds, generated artifacts, and local runtime defaults.
• Select one canonical representation for cross-language protocol constants.
• Generate or derive TypeScript, Noir, Solidity, and Rust consumers where practical.
• Keep circuits/lib/src/configs/ as the owner of circuit-bound generated configuration, rather than copying circuit bounds into unrelated layers.
• Remove hand-maintained BFV and committee duplicates from deployment scripts, fixtures, and helper crates.
• Add drift checks for values, parameter hashes, configuration IDs, and generated artifacts.
• Keep local operational constants, such as mailbox limits and test fixtures, separate from protocol configuration.

Acceptance criteria

• Every protocol-bearing constant has one documented source of truth.
• Generated consumers identify their generator and fail CI when stale.
• Rust, Noir, deployment tooling, Solidity configuration, and fixtures agree on the active BFV parameter hash and committee shape.
• Secure and insecure presets have explicit cross-language compatibility tests.
• The migration does not silently change deployed parameter identities, circuit witness shapes, committee thresholds, or configuration IDs.