docs: add changelog entry for enum duplicate declarations

[prql-bot]

#6164 added three new diagnostics to enum handling — an enum whose name collides with an earlier declaration, a repeated member name, and a member called _self now all fail to compile where they previously resolved to whichever declaration came last. Its sibling #6150 landed the same day with a **Language** entry; this adds the matching one, per the "follow-up PR containing just the changelog entry is welcome" note in the contributing docs.

Not framed as a breaking change: enum itself is unreleased — #6104 added it and is still under [unreleased] in the Features section — so no published program can have relied on last-declaration-wins here. The entry just records the new diagnostics for anyone tracking main.

Changelog-only, so there's nothing to test beyond the markdown lint.

Found during the nightly review of the last 24 hours of commits.

[prql-bot]

The two new diagnostics are described accurately — duplicate declarations of {ident} comes from RootModule::declare in semantic/module.rs, and duplicate declarations of {ident}.{name} plus the _self rejection from fold_type_def_stmt in semantic/resolver/stmt.rs. The closing sentence is the problem.

"This is a small breaking change — enums that relied on the last declaration winning now fail to compile" isn't true of any released version. enum declarations have never shipped: 0.13.14 (2026-07-24) carries enum only as a lexer keyword (just("enum") in prqlc-parser/src/lexer/mod.rs) with no statement parser behind it, and #6104, which added enum_def, merged 2026-08-07 — its own entry is still under [unreleased] three lines below this one. So no published program can have relied on last-declaration-wins for enums, and the 0.13.15 notes would carry a breaking-change warning in the same section that introduces the feature. The #6150 entry directly above uses that same sentence correctly, because import did ship.

Worth noting the review on #6164 reached this conclusion explicitly — "it also adds a CHANGELOG.md entry, which this one skips on the grounds that enum is unreleased — that reasoning checks out, #6104 is still under [unreleased]" — so the premise for the follow-up ("If there's a missing entry…") is at least arguable. Recording the new diagnostics still has value for anyone who picked up the feature from main; dropping just the breaking-change sentence keeps that without the misleading framing. If a maintainer would rather have nothing here, closing is also a fine outcome.

Verified the suggestion against prettier --check with proseWrap: always — the merged line lands at 79 columns and passes.

[prql-bot]

Closing — the review is right and it undercuts the premise, not just the wording.

I opened this reading #6164 as a breaking change to released behaviour, by analogy with its sibling #6150. It isn't: enum arrived in #6104, which is still under [unreleased] three lines above where this entry would go, so 0.13.15 will introduce the feature and its diagnostics in one entry. A separate line saying duplicate enum declarations are now rejected would just be redundant with the feature entry a maintainer writes at release time.

Dropping only the breaking-change sentence, as the review offers as an alternative, would leave an accurate but redundant entry — so the cleaner outcome is nothing here. The #6164 review had already reached this conclusion; I missed it.

No change needed to #6164.