docs(changelog): the BDC entry documents the next release, not a published one

[dgunning]

#990 branched from 2df53a2c on 2026-08-07, when the entries now dated 5.46.0 were still under [Unreleased]. It added its own entry to that block, and eight days later the squash merge applied the hunk by context — into a section that had since been released.

Two consequences, both wrong in opposite directions:

• 5.46.0's published changelog claims a feature it does not contain. That release went out on 2026-08-07; the BDC parsing work merged on 2026-08-15.
• The next release would ship the BDC work undocumented, because [Unreleased] had no entry for it at all.

Moved to [Unreleased] under a ### Changed heading. I extended the text with the two label-shape fixes and the ticker count, since those are what a reader upgrading actually needs to know, and added the (GH #990) reference. 5.46.0 keeps its other 22 entries unchanged, and the entry appears exactly once in the file.

Found while checking whether [Unreleased] was ready to be cut as 5.49.0 — it wasn't.

Worth knowing for any long-lived branch: a CHANGELOG hunk written against [Unreleased] does not follow that heading when a release is cut underneath it. Git matches context lines, and the context is the neighbouring entries, which move into the dated section with it.

🤖 Generated with Claude Code

[dgunning]

Superseded by #1045, which folded this correction into the 5.49.0 release commit. Keeping the two apart risked the same squash-merge collision that #1043 hit earlier today, since both touch adjacent lines of CHANGELOG.md. The entry now sits under ## [5.49.0] - 2026-08-15, and 5.46.0 keeps its other 22 entries unchanged.