Fix rolling release notes provenance: avoid shell command substitution

[mark-e-deyoung]

Problem

The current rolling release notes are generated with an unquoted shell heredoc containing Markdown backticks around shell expansions, for example:

- Upstream commit: `${UPSTREAM_BASE_SHA}`
- SemperSupra candidate: `${CANDIDATE_SHA}`
- Short build id: `g${SHORT_SHA}`

In an unquoted heredoc, backticks are shell command substitution syntax. The live semper-exp-current release demonstrates the defect: the human-readable release body contains blank upstream commit, candidate, short build id, and inline-code references even though the machine manifest/assets are present.

This is a provenance defect in the public distribution surface.

Required fix

Generate release notes without allowing shell command substitution. Use a robust construction such as Python, printf, or a quoted heredoc plus explicit substitution that treats Markdown backticks literally.

Add a verification step that fails if the rendered release notes do not contain the exact candidate SHA and upstream base SHA.

Acceptance

• rendered release body contains the exact UPSTREAM_BASE_SHA;
• rendered release body contains the exact CANDIDATE_SHA and short id;
• literal Markdown backticks remain literal text;
• no command-substitution stderr is produced;
• the credential-free post-publish verifier checks the public release body provenance in addition to the machine manifest;
• no engine-semantic change is involved.

Current evidence

The live rolling release tag currently points to 71c69952f22d098da4ed2380d93f429bd43f088b, while its human release body has blank SHA/build-id fields. Treat the machine manifest/tag ref—not the broken release-body prose—as authoritative until this is fixed.

Relates to the rolling publication hardening stack (#2, #3, #4).