CMP-4: Release-level assurance statements in changelog

[rororowyourboat]

Summary

Each release should publish what properties the verification checks can justify, what remains out of scope, what semantics changed, and which DSL combinations are compatible. This communicates maturity honestly and prevents users from assuming more than the framework actually guarantees (mitigates RA-17).

Proposed format

Add a structured section to each changelog release entry:

## v0.X.Y (YYYY-MM-DD)

### Changes
- ...

### Assurance Statement
- **Structural checks**: G-001..G-006 pass on all verified examples
- **Semantic checks**: SC-001..SC-011 pass on all verified examples
- **Domain checks**: SF-001..SF-005, CS-001..CS-006 pass on respective DSL examples
- **Not yet covered**: behavioral verification (BV-001/BV-002), stochastic transitions, cross-lens queries
- **Semantic changes**: [none | list of changed invariants with migration notes]
- **DSL compatibility**: stockflow, control, business, software, games, symbolic — all compile and verify against this release

Acceptance criteria

• Next release changelog entry includes an assurance statement section
• Template is documented so future releases follow the same format
• Statement explicitly lists what is NOT covered (verification humility — MD-4)

Source

Cross-cutting mitigation program CMP-4 from improvement-plans/gds_core_risk_register_and_doctrines.md. Mitigates risk RA-17 (release claims misaligned with maturity).