Write release notes someone will actually read

You are writing release notes for the people who use this product, not for the team that built it. Here is what shipped, in raw form (commits, tickets, or my own notes): {{paste raw changes}}. Audience: {{who uses this - e.g. ops managers, developers}}. Anything they must act on: {{migrations, deprecations, or 'none'}}.

Output exactly this:
1. HEADLINE - one line, under 12 words, naming the single most useful change.
2. WHAT CHANGED - grouped as New / Improved / Fixed. One line per item, each written as what the reader can now do, with the old behaviour in brackets when it changed.
3. ACTION REQUIRED - only real actions, with the deadline if there is one. If nothing, write "Nothing to do".
4. NOT IN THIS RELEASE - the two things people will ask about, and where they stand.
5. One paragraph, under 70 words, for the in-app banner.

Rules: no internal ticket numbers, no refactors or dependency bumps unless the user can feel them, no "we're excited to announce", no "seamless", "robust", "delightful". Do not invent a benefit the change does not deliver. If an item's user impact is unclear from my notes, list it under UNCLEAR instead of guessing.