fix: validate slot duration and epoch configuration invariants (PM-20013)

[m2ux]

Summary

Implement three-layer defense-in-depth for slot duration configurability: constructor validation, on-chain config storage with startup consistency check, and config hash in block headers. Addresses Least Authority Issue J (High severity).

🎫 PM-20013 📐 Engineering

---

Motivation

CreateInherentDataConfig aggregates consensus-critical parameters — sidechain slot configuration (on-chain) and mainchain epoch configuration (off-chain config files) — without cross-validation, invariant enforcement, or on-chain commitment. Nodes with differing parameter values compute divergent slot indices and epoch boundaries for the same wall-clock time, causing silent consensus divergence.

The existing codebase contains an explicit TODO (ETCM-4079) acknowledging missing validation for the epoch-duration/slot-duration divisibility constraint.

---

Changes

Implementation (coming next):

• Layer 1 — Constructor Validation: Replace #[derive(new)] on CreateInherentDataConfig with fallible fn new() -> Result enforcing epoch/slot divisibility and non-zero invariants. Add mc_* field validation to MidnightCfg.
• Layer 2 — On-chain Config Storage: New pallet-consensus-config storing mc_epoch_config via genesis config, exposed via runtime API. Startup consistency check in service.rs comparing local config against on-chain values.
• Layer 3 — Config Hash in Headers: DigestItem::Consensus with new engine ID depositing config hash per block in on_initialize, following pallet-version pattern.
• Chain Spec Updates: Add consensus_config to RuntimeGenesisConfig across all chain spec builders.
• Tests: 14 planned test cases covering constructor validation, pallet storage, config hash, startup consistency, and backward compatibility.

---

📌 Submission Checklist

• Changes are backward-compatible (or flagged if breaking)
• Pull request description explains why the change is needed
• Self-reviewed the diff
• I have included a change file, or skipped for this reason: planning phase — no code changes yet
• If the changes introduce a new feature, I have bumped the node minor version
• Update documentation (if relevant)
• No new todos introduced

---

🔱 Fork Strategy

• Node Runtime Update
• Node Client Update
• Other
• N/A

---

🗹 TODO before merging

• Ready for review

[github-actions]

KICS version: v2.1.16

Category Results CRITICAL 0 HIGH 0 MEDIUM 96 LOW 12 INFO 83 TRACE 0 TOTAL 191	Metric Values Files scanned 31 Files parsed 31 Files failed to scan 0 Total executed queries 73 Queries failed to execute 0 Execution time 8