Write release notes from a conventional-commit log (breaking changes, reverts, cherry-pick duplicates, semver bump)

# Task: write the release notes `commits.txt` lists every commit since the last release, newest first, after two header lines (`previous:` = last released version, `release_date:`). Each commit is one line `<hash> <subject>`; indented lines after it are that commit's body. Write `RELEASE_NOTES.md` in this directory following these rules exactly. You may write it by hand or with a script. No network. 1. Conventional subjects look like `<type>(<scope>)!: <description> (#<PR>)`; the `(<scope>)`, the `!` and the ` (#<PR>)` suffix are each optional. A subject that does not have this shape (merge commits, "WIP ...") is excluded. 2. `feat` goes to **Features**, `fix` to **Fixes**, `perf` to **Performance**. All other types (`chore`, `docs`, `test`, `ci`, `style`, `refactor`, `build`, ...) are excluded, unless the commit is breaking. 3. A commit is breaking if it has `!` before the `:` or a body line starting with `BREAKING CHANGE: `. Breaking commits of ANY type are listed only under **Breaking changes** (not also in their type section). Their bullet text is the text after `BREAKING CHANGE: ` if there is such a line, otherwise the description. 4. A `revert:` commit whose body contains `This reverts commit <hash>.` removes itself and the commit with that hash. If that hash is not in the list, only the revert commit itself is excluded. Revert commits never appear in the notes. 5. If the same PR number appears on more than one included commit (cherry-picks), list it once, using the commit that appears first in the file. 6. Bullet format: `- **<scope>:** <text> (#<PR>)` when there is a scope, else `- <text> (#<PR>)`; leave out ` (#<PR>)` when the commit has no PR number. `<text>` is the description (or the breaking text from rule 3) with its first letter upper-cased and any trailing period removed; everything else is kept as written. 7. Inside a section, bullets with a PR number come first, sorted by PR number ascending, then bullets without a PR number in file order. 8. Version: from `previous` vX.Y.Z, bump major (to X+1.0.0) if anything breaking is included, else minor (X.Y+1.0) if any feature is included, else patch (X.Y.Z+1). 9. Layout: the first line is `# v<version> - <release_date>`. Then the non-empty sections in this order, each as a `## ` heading: `## Breaking changes`, `## Features`, `## Fixes`, `## Performance`, each followed by its bullets. The file contains only these heading lines, bullet lines and blank lines. The grader parses `RELEASE_NOTES.md` and compares the title line, the section order and every bullet line exactly (trailing spaces ignored).