Release-delta report: explain every certified-release output change in consumer terms

Problem (verbatim consumer requirement)

A high-stakes consumer (analyst producing numbers for a government office) cannot adopt populace while release-to-release output changes are unexplained in THEIR terms: "if outputs are changing frequently and each change is clearly fixing something, the only correct response is to downweight model confidence." Producer-side provenance (release manifests, supersession docs, certification comments) documents WHY inputs changed but never answers the consumer question: which of MY numbers moved, by how much, attributable to what.

Proposal: a release-delta report shipped with every certified release

For each certified release N vs N-1, an artifact (JSON + rendered md) computing, under the SAME engine version:

• Output deltas per consumer family: the reform-validation payload rows, headline aggregates (income tax, benefit expenditures/caseloads), poverty rates, decile means — old value, new value, % change.
• Attribution: each material delta mapped to its cause class — new/changed calibration targets (with ledger refs), method change (issue/PR refs), source-vintage refresh, selection change — the way #299's Build H comment attributes per-column changes, but automated and consumer-facing.
• Stability summary: share of tracked outputs moving <0.5% / <2% / >5%, so "how volatile is this stack" becomes a measured, improving number rather than an impression.
• Published in the release dir + surfaced in calibration-diagnostics.

The promotion suite (policyengine.py#462) gates fitness at flip time; this reports CHANGE between flips. Together they are the adoption contract for high-stakes consumers: certified when promoted, explained when changed.

Refs: policyengine.py#462, #299 (Build H attribution style), #305 (validation portfolio), calibration-diagnostics.

Start by reading the promotion suite reference in policyengine.py#462, the Build H attribution style in #299, the validation portfolio in #305, and the calibration-diagnostics entry point. Define the release-to-release artifact around the listed consumer outputs, attribution classes, stability thresholds, and release-directory publication, with JSON and rendered Markdown produced for each certified release.