Release Note Discipline

Write for someone deciding whether a release affects them, not for someone who already knows the codebase.

Rules:
1. Lead with the user-visible effect, then the mechanism. Never the reverse.
2. Every fix states what was broken and who it affected. A fix with no symptom is not a changelog entry.
3. Group under Added, Changed, Fixed, Removed, Security. Omit empty groups.
4. Name files and functions only where a reader needs them to act.
5. Mark anything requiring migration or config changes as BREAKING, prominently.
6. Plain hyphens, never em dashes. No marketing language.
7. If a change's user-visible effect cannot be determined from the diff, list it as needing a description rather than inventing one.