OP-OPS-04

Operator-supplied keys. Ade supports both KES key flows: (a) Ade-native ade_node --mode key_gen_kes --out-file PATH emitting an ade.kes.seed.v1 envelope loaded via ade_runtime::producer::keys::load_ade_kes_signing_key; (b) cardano-cli node key-gen-KES emitting a 608-byte KesSigningKey_ed25519_kes_2^6 envelope loaded via ade_runtime::producer::keys::load_kes_signing_key_skey. After PHASE4-N-P S5 the cardano-cli path routes through the Ade-owned BLUE deserializer (ade_crypto::kes_sum::Sum6Kes::raw_deserialize_signing_key_kes); both flows produce a KesSecret whose inner is ade_crypto::kes_sum::Sum6Kes::SigningKey (BLUE-owned algorithm). VRF and cold (Ed25519) keys continue to be operator-supplied via cardano-cli text-envelope .skey files. Private-key material never crosses into BLUE — the entire RED custody surface lives under crates/ade_runtime/src/producer/{keys,signing,ade_kes_envelope}.rs. Wrong-size payloads fail-close via KeyLoadError::UnsupportedExpandedKesKeyFormat; structurally-invalid 608-byte payloads fail-close via KeyLoadError::KesParse(KesParseError::*). Mechanical enforcement: ci/ci_check_private_key_custody.sh + ci/ci_check_kes_envelope_closed.sh + ci/ci_check_kes_sum_compatibility.sh. OP-OPS-04-KES-PERIOD-ANCHOR (public-venue hardening): at producer-shell init the opcert.kes_period is the ABSOLUTE KES period the key's evolution-0 is certified for; the shell verifies the INJECTED current absolute period (derived from the genesis KES anchor + the durable tip slot, NEVER the raw key evolution index) is within [opcert_start, opcert_start+63], then anchors evolution-0 at opcert_start and evolves the key by (current - opcert_start) so it signs at the current period -- fail-closed KesPeriodBelowOpCertStart / KesPeriodPastOpCertEnd / KesEvolutionFailed outside the window. Signing stays RED/shell; opcert verification stays BLUE/core; no wall-clock in the deterministic shell (the period is injected).