Write release notes by hand

[TerrifiedBug]

The 0.3.0 release notes read:

What's Changed

• Make the app the product, not the CLI by @TerrifiedBug in Make the app the product, not the CLI #19
• Judge zip entry names, not standardized paths by @TerrifiedBug in Judge zip entry names, not standardized paths #20

That is what was merged. It is not what changed for the person installing it — nothing in it mentions that the hotkey is now recorded rather than picked, that the transcript banner gained Delete, or that seven commands went away.

What this does

CHANGELOG.md holds the notes, in the same register as the README — what changed for a user, not a log of commits. The release job reads the section matching the tag and publishes it.

The read happens before the build, not after: a version with no section fails in seconds rather than once Apple has finished notarizing it. An empty section counts as missing, because it is the same mistake.

body and generate_release_notes are both set. GitHub puts the written notes first and appends its own merged-PR list and full-changelog link underneath, so the notes lead and the provenance stays one click away.

Older releases are left alone; the file says where to find them.

Checked

• extraction returns the 0.3.0 section, 64 lines, stopping cleanly at the next ## heading (0 leaked);
• a version with no section extracts 0 bytes, which trips the guard and fails the job;
• the workflow still parses, 10 named steps in order.

The published v0.3.0 notes have been rewritten from this file so the release and the changelog agree.