[feature] Render the text of a BREAKING CHANGE footer

[namolnad]

0.5.0 learned to recognise a BREAKING CHANGE: footer, but only far enough to tag the commit. The footer's own words — the part telling somebody what to do about it — became a separate, unattached entry. Which is why 0.5.0's release notes needed a hand-written section afterwards.

What changes

A footer describes the commit rather than standing on its own, so it is now read as the commit's breaking change instead of as an entry:

• its text rides with the entry it describes, and wrapped footers are joined
• the entry earns the breaking tag exactly as a ! would, so chore: tidy analytics with a footer files under Breaking Changes
• footers are read whichever style the subjects use, delimited included

RawLog carries the description alongside the sha and author it already carries, which keeps it available to a per-line component without the commit body having to survive entry extraction.

Printing it

<< breaking_change >> is a new format component:

- title: Breaking Changes
  tags: [breaking]
  format_string: ' - << tags >> << message >> — << breaking_change >>'

### Breaking Changes
 - |breaking||feat||api| drop the v1 endpoints — v1 is gone. Move to v2, which takes the same parameters and returns an envelope.
 - |breaking||chore| tidy analytics — the express_start event is gone
 - |breaking||feat||ui| restyle the header

That third entry has no footer, and its — is dropped rather than left dangling. The rule is general, not specific to this component: a separator preceding a component which renders nothing is omitted, which also tidies << tags >> on an untagged commit. The separator opening a line is kept, being a bullet rather than a join — otherwise an untagged entry would lose its -.

Finch describes what it breaks

.finch/config.release.yml takes a Breaking Changes section. Run against commits shaped like this release cycle's:

### Breaking Changes
 - Adopt the Swift 6 language mode — building from source now requires a Swift 6.0 toolchain. - [PR #152]
 - Read Conventional Commits by default — commit messages are read as Conventional Commits. Projects on the original convention set commit_style: delimited. - [PR #153]

Had this existed a day earlier, 0.5.0's notes would have carried both breaking changes on their own.

Test plan

• 44 tests, 0 failures. New coverage for footer extraction, the hyphenated BREAKING-CHANGE: spelling, footers under the delimited style, and that a footer no longer opens an entry.
• The end-to-end conventional snapshot now includes a !-plus-wrapped-footer commit, a footer-only commit, and a breaking commit with no footer — the three cases that differ.
• Ran the real binary over each shape, and over commits shaped like this cycle's, through Finch's own release config.
• swiftformat --lint . clean.

🤖 Generated with Claude Code