docs(changelog): v1.25.19-1 at reading length, headings kept in the tag

A human review of the v1.25.19-1 release page found it long and flat. Both causes are fixed here.

The section was 277 lines and 2368 words in 36 bullets. It is now 101 lines and 796 words in 14, each bullet a bold lead plus at most two sentences, ordered consumer-first (what is in the image, then security posture, then verification) with the project plumbing collapsed to three bullets. The ### Pinned versions block is byte-identical to what shipped and the older sections are untouched. Keep a Changelog link references are added for every release, so each version heading links to its compare view.

The flat page came from scripts/tag-release.sh, which created the tag with git's default --cleanup=strip. That mode deletes every line beginning with #, so the annotation carried no headings and the release page rendered one list of fifty bullets. The tag is now created with --cleanup=whitespace. The dry run counts the headings in the body against the section plus the footer's own, and the real run reads them back from the created tag and deletes the tag on a mismatch. Proven in a throwaway clone with a five-heading body: 0 headings survive the default, 5 survive the fix, and with the default restored the new check fires and removes the tag.

CONTRIBUTING's ## Releasing now names the release commit subject the push rule accepts, chore(release): vX.Y.Z or vX.Y.Z-N.

Vale no longer lints CHANGELOG.md, as in the reference project. A dated record is not reworded to satisfy a linter, and the reference links are the format's own shape (each drew a ReferenceLinks alert, and an inline link would break the changelog standard's heading regex and the tag script's extraction).

The live release page was repaired through the API with this section reflowed into paragraphs plus the generated footer. The tag annotation stays as cut. Rendered through the Markdown API, the new CHANGELOG.md has six version headings, each carrying its compare link, and the heading ids are unchanged, so the footer permalink still resolves.

Found on the way and not fixed here: the release component's reflow in public-sector/pipeline joins fenced code lines into one line, so the cosign commands in any release footer with a code fence render unrunnable. That takes a merge request in the pipeline project.