[cpp-RCP-parity-A] Release integrity: close the tag/main drift and release-pipeline gaps #122

Background

c-RCP (the project's reference implementation) just closed a tag/main drift of its own (v0.477.0 → v0.479.0, 5 commits) and has a hardened release pipeline: a release.yml that verifies every shipped safety artifact declares the version actually being released (added after a real incident, c-RCP issue c-RCP-09, where artifacts drifted ~184 versions stale), plus a standalone per-PR version-sources-agree CI job.

A parity audit against cpp-RCP (2026-08-21, verified against cpp-RCP main@ba31fa1) found cpp-RCP has the same class of problem, worse in degree, and is missing the guard rails c-RCP now has to prevent it recurring.

Findings (verified against current main, not docs)

1. main is 26 real commits ahead of the latest tag v2.19.0 (git describe --tags → v2.19.0-26-gba31fa1). This isn't just an artifact-regen commit — it includes a documented BREAKING change (fix: v2.24.0 — PWM_OUT write semantics + GPIO input-pin masking (BREAKING)) and the entire Table 30/33 Row-2 evt[2:0] validation feature (8 endpoint types, PRs feat: implement Table 30 Row-2 evt[2:0] validation — pilot (shared predicate + I2C dispatch wiring) #114-121), all unreleased. CMakeLists.txt on main says VERSION 2.26.0; the tag says 2.19.0.
2. The safety artifacts currently committed in the tree (sbom.json, provenance.json, sci.json, qualify-report.json) were last regenerated for v2.19.0 (5179580, 2026-07-30) and all report "toolVersion": "0.17.0" — stale relative to the now-pinned v0.18.0 cpp-FuSa tool.
3. release.yml has no step verifying shipped artifacts declare the version being released — c-RCP's exact c-RCP-09 gate has no cpp-RCP equivalent anywhere in the 248-line file.
4. No per-PR version-sources-agree job exists (grep -n "version-sources-agree" .github/workflows/*.yml → nothing). Porting this isn't a drop-in: cpp-RCP's .fusa.json has no project.version field at all (only a config-schema "version": "1") — CMakeLists.txt's VERSION 2.26.0 and include/rcp/version.hpp's kVersion currently agree, but nothing enforces it going forward, and a schema decision (add project.version to .fusa.json, or do a two-way check) is needed first.
5. release.yml is missing the IEC 62443 gap-report step c-RCP's has (cfusa iec62443 --sl SL-2) — no iec62443 step and no such cpfusa invocation anywhere.

Checklist

• Cut a release tag closing the 26-commit / breaking-change drift behind main — do this first, before the drift grows further (mirrors what was just done for c-RCP: v0.477.0 → v0.479.0)
• Add a version-declaration release-gate verification step to release.yml (mirrors c-RCP's c-RCP-09 gate) — requires first deciding how .fusa.json represents the project version (add a project.version field, or verify CMakeLists.txt/version.hpp two-way)
• Add a per-PR version-sources-agree CI job, once the schema question above is settled
• Add the missing IEC 62443 gap-report step to release.yml
• Create CHANGELOG.md — see the sibling issue for CHANGELOG-specific detail; listed here too since it's part of the same release-integrity theme

Not in scope here

Runtime feature work (CAN XL fragmentation, requirement-schema fields, MC/DC, etc.) is tracked in the sibling roadmap issues — see the parent tracker.