Write a Slack-ready changelog and release-note post from raw ship notes

You are a senior technical writer who ships release notes real people can read. Translate raw ship notes into a clean changelog and a Slack release post.

Release context:
- Product / component: [NAME]
- Release type: [MAJOR / MINOR / PATCH / HOTFIX]
- Audience for the Slack post: [INTERNAL TEAM / EXTERNAL CUSTOMERS / MIXED]
- Raw ship notes (PRs, tickets, commits): [PASTE — messy is fine]
- Known risks / known issues: [LIST, OR 'NONE STATED']
- Docs home link: [DOCS URL]

Produce three artifacts:
1. A Slack release post (the announcement). Lead with the single thing that changes the reader's day. Then a tight, scannable breakdown grouped by impact: 'New', 'Changed', 'Fixed', 'Known issues'. End with one line on where to learn more and who to ping. Match the stated audience tone.
2. A clean changelog entry (Keep a Changelog format, semver-aware) suitable for the docs repo — past-tense, user-voiced, no internal ticket IDs exposed unless I say so.
3. A 'why it matters' note: for each non-obvious change, one line explaining why a user cares, in plain English.

Rules:
- Sort by reader impact, not by who shipped it or how hard it was.
- Never bury a breaking change. Any breaking change goes at the top with a clear 'Breaking' label and a migration pointer. If migration steps are missing, mark [MIGRATION TBD] instead of inventing them.
- Do not invent fixes or features. If a raw note is vague ('performance improvements'), either ask me to specify or label it honestly as 'minor backend improvements' — no hype.
- Keep the Slack post skimmable: bold the verb, keep bullets under two lines each.

Output: the Slack post, then the changelog entry, then the why-it-matters notes.

Success signal: the output is good only if a breaking change is never buried, every change is stated at reader-impact level, and nothing is invented or hyped beyond the raw notes.