docs: make release notes user-facing

[Pluze]

Why

Make every GitHub Release useful to readers deciding whether and how to upgrade, instead of presenting delivery logs and maintainer-only evidence.

What changed

• Rewrote all 17 published Release notes around user-visible behavior, compatibility, safety warnings, and required upgrade actions.
• Preserved every published tag, title, date, and asset while removing commit IDs, workflow links, commands, test inventories, CI routing, hashes, and byte counts from public notes.
• Added the reader-facing rule to the release manual, root agent policy, and documentation-maintainer skill.
• Added a Release notes template and changed future draft Releases to start from it instead of an automatically generated commit list.
• Added repository evidence for the template and workflow contract.

No App behavior, scientific calculation, project, result format, public API, component version, release tag, or release asset changed.

Evidence

Online Release audit
PASS: 17/17 published notes use reader-facing sections
PASS: no commit hashes, Actions links, commands, test inventories, CI Gate references, or asset digests remain
PASS: tag, title, publication date, and asset metadata are unchanged

python -m unittest discover -s .github/scripts -p 'test_*.py'
PASS: 19 tests

python .github/scripts/validate_agent_skills.py
PASS: 7 skill contracts

runFocusedSpecs("tests/specs/tests/labkittest/TestCatalogSpec.m")
PASS: 47/47 identities

buildtool docsCheck
PASS: 236 narrative pages, 148 API pages, 389 generated files compared byte-for-byte

buildtool changedFast
PASS: 64/64 identities

Risks and follow-up

• Historical Release wording is now shorter, but preserves the original user-visible behavior, compatibility decisions, and safety guidance.
• Future drafts still require a developer to replace template comments with release-specific user content before publication.
• No interactive or scientific validation was required because this change does not alter App behavior or scientific outputs.

Author confirmation

• The final diff matches the stated scope and contains no unrelated change.
• The evidence above covers required local and manual validation; every remaining unverified boundary is explicit.
• The diff contains only synthetic or generic public data, with no private App details, lab identifiers, local paths, or recognizable sample values.