Rework MI-19 as Release Approval Gating; sharpen the MI-12 boundary

[AlexKantor87]

Reworks MI-19 into Release Approval Gating and sharpens its boundary with MI-12.

MI-19 — Release Approval Gating

Renamed and broadened. The gate applies to any versioned release — a software artifact, an infrastructure-as-code change set, or both — not only application software. The URL slug is unchanged to preserve existing links.

Requirements refocused on outcomes rather than implementation:

• The pipeline-specific enforcement requirement ("MUST be enforced by the release pipeline... pipelines MUST verify... MUST fail") is now a mechanism-neutral property: production deployment MUST be technically prevented while the required approval is absent or revoked. The ways to implement that (pipeline, environment protection rules, ITSM lock, policy engine) move to Examples & Commentary.
• Approval binding is now to an immutable, content-addressable identity rather than the inline examples ("signed artefact digest or tagged commit SHA") — a tag is mutable, and a commit identifies source rather than the released artefact. This follows the wording direction in SDLC022 - Code Review Feedback #81.
• The two emergency-release requirements are removed: control bypass is being consolidated into a dedicated control (SDLC022 - Code Review Feedback #81) rather than restated per mitigation.

Regulatory mappings added, following the format piloted on MI-1 in #88: NIST 800-53 (CM-3, CM-5, CA-6), EU DORA (Art. 9(4)(e), RTS Arts. 16(2) and 17(1)), UK FCA/PRA (SYSC 15A, SS1/21, FCA technology-change review), FFIEC DAM (II Governance, VII Maintenance).

Quality pass: the empty ## Links section is populated; lowercase cross-refs; meta-reference phrasing removed from the Description; the "time-limite" typo resolved by removing the emergency tier from the tiered-approval example.

MI-12 / MI-19 boundary

Reviewed side by side, MI-19's automated-checks paragraph re-enumerated MI-12's gate criteria (tests passed, vulnerability thresholds, scan attestations), making the two controls read as duplicates. They answer different questions:

• MI-12 evaluates the current technical posture of an artefact at each deployment event — the same version can pass today and be blocked tomorrow as new findings emerge, scans age, or remediation timelines are breached.
• MI-19 issues a durable, attributable approval record per release, bound to the release identity; that approval state is one of the conditions a deployment gate verifies.

Both descriptions now state this boundary explicitly and cross-link each other. MI-19's automated-checks paragraph now describes confirming that required evidence and decisions exist (mi-12, mi-1, mi-20, mi-3) and producing the approval record, leaving posture evaluation to mi-12.

MI-12's override requirements and its Emergency Overrides example are removed for the same reason as MI-19's: bypass consolidation per #81.

Refs #96, #81

[AlexKantor87]

The MI-21 work has moved to its own pull request: #100.