Standardize release notes: always significant-change highlights, never a size-based trim

[Marcogn]

Summary

This replaces the ad hoc "dump the whole section, unless it's too long" approach with one uniform rule, applied the same way across CoverDex, 3DSAppManager, and ThePatientGamerHelper's release.yml:

• The GitHub Release body is now always just the significant-change bullets extracted from CHANGELOG.md's matching section — never the full section text, and never gated by a character-count or line-count cutoff. That inconsistency (1500 chars in one repo's proposal, 40 lines in another's) is exactly what prompted this pass.
• CLAUDE.md gets a new "Changelog Entries" section documenting the convention the extraction depends on: every version section leads with flat - **One-line summary.** ... bullets, so the highlights are always already "ready" in CHANGELOG.md — the workflow no longer has to guess by trimming or reflowing prose at release time.
• A version section with no bulleted highlights at all (only this project's initial [1.0.0] prose entry, written before the convention existed) falls back to publishing the whole section as-is — a structural fallback for a section with nothing to extract, not a size-based judgment call.
• The release notes always end with a link back to CHANGELOG.md's matching section, computed via GitHub's real heading-anchor slug algorithm.

Supersedes #27, which proposed a 1500-character length cutoff — closing that PR in favor of this unconditional approach.

Test plan

• python3 -c "import yaml; yaml.safe_load(open('.github/workflows/release.yml'))" — YAML parses.
• Ran the highlight-extraction awk logic standalone against a simulated multi-bullet [1.1.0]-style entry with a nested elaboration bullet — correctly extracts just the top-level bold lead-ins, ignoring the nested one.
• Verified the slug computation against the real ## [1.0.0] heading (#100).
• Not run end-to-end via an actual workflow_dispatch (would cut a real release).

---

Generated by Claude Code