changelog-entrylisted

# changelog-entry Draft the `## [Unreleased]` entry for what just changed. Keep a Changelog format, written for the person upgrading. ## Read the CHANGELOG's own rules first **Always.** Every repo of mine states its conventions in its own CHANGELOG.md header, above the first `##`, and they differ per project. That header outranks everything below. Two real examples of what lives up there: - **poops** — the `[Unreleased]` heading takes a short title after an em dash, and the entry opens with one paragraph saying what was wrong before. Those two become the title and description of a generated changelog post, so they are not decoration. Write plain Markdown; template tags get fenced automatically. - **code-preview-element** — call out anything that changes the **DOM the element produces**, the **CSS an author may already be targeting**, or the **contents of the preview iframe**. None of the three shows up in a function signature, so none of them is visible in the diff to a reader. If the header asks for something not listed here, do that instead. ## Steps 1. `git diff` (or `git diff --staged`, or against the merge base) to see what landed. 2. Read `CHANGELOG.md`'s header block for the house rules. 3. Read the last two or three released entries. They are the voice sample — match their length, their bolding, their level of detail. 4. Write the entry under `## [Unreleased]`, in the right group. ## Groups `### Added`, `### Changed`, `### Deprecated`, `### Re