docs(changelog): condense the [Unreleased] section to the brevity standard

[marius-bughiu]

What

Condenses the entire ## [Unreleased] section of CHANGELOG.md to the brevity convention codified in CLAUDE.md (from #279), and mirrors a short version of that convention into CONTRIBUTING.md's Versioning section.

Closes #278.

Why

Every [Unreleased] entry had grown into a multi-hundred-word implementation walkthrough — private field names (_words, _version, head/count), bit-shift/probe-chain mechanics, JIT/codegen rationale, and a per-facet "parity note" per change. That detail belongs in the PR description or code comments, not a changelog a caller reads to decide whether/how to upgrade.

It's also a release-safety issue: .github/workflows/release.yml extracts the whole ## [X.Y.Z] section verbatim as the GitHub Release body, and GitHub caps release bodies (~125k). An accumulation of paragraph-per-change entries in one section risks exceeding that and failing the release (this has bitten a prior release). The [Unreleased] section becomes the next release section, so it is squarely on the release path.

What changed

• CHANGELOG.md — each [Unreleased] change is now one tight, user-facing entry stating what observably changed and why it matters to a caller, ending with Closes #NNN where an issue exists. The per-type test/benchmark/dashboard/docs bullets and the parity notes are dropped (they're how the feature ships, not user-facing changes). The already-conventional BitSet.Flip ### Changed entry (the perf(BitSet): add AggressiveInlining to Flip to match Get/Set (#253) #277 example) is kept as-is. The section drops from ~11,272 words to ~987 (~91%).
• CONTRIBUTING.md — a new ### Changelog entries subsection under Versioning mirrors the rule for human contributors (the canonical guide previously only said "update CHANGELOG.md first"), and points at CLAUDE.md for the agent-facing copy.

Scope notes

• Issue checkbox 1 named DisjointSet / Deque / BitWriter/BitReader as examples, but all 13 [Unreleased] entries were equally verbose and all sit in the same release section — condensing only three would not keep the extracted release body within limits, so the whole section was brought to standard.
• Checkbox 2 (back-fill already-released sections like [2.2.0]) is intentionally left out: it's marked optional/lower-priority, those sections are historical, and the size risk is per-release-section so past sections are not on the release path. Left untouched to keep this diff focused.
• Checkbox 3 (confirm CLAUDE.md reads clearly + mirror into CONTRIBUTING.md): CLAUDE.md's guidance from docs: add CLAUDE.md with a CHANGELOG brevity convention #279 reads clearly as-is; the CONTRIBUTING.md mirror is included here.

No code, tests, or public API touched — docs only.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Updates repository documentation to enforce the changelog brevity convention so release notes remain user-focused and within GitHub Release body size constraints.

Changes:

• Condenses CHANGELOG.md’s entire ## [Unreleased] section into short, caller-facing entries.
• Adds a “Changelog entries” subsection to CONTRIBUTING.md under Versioning, mirroring the brevity rule for human contributors.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
CONTRIBUTING.md	Documents the changelog brevity convention and explains the release-note size constraint rationale.
CHANGELOG.md	Rewrites the [Unreleased] entries to the “few sentences, user-facing” standard.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

CONTRIBUTING.md:121

• The new guideline says “End the entry with Closes #NNN”, but the same PR’s condensed ## [Unreleased] entries include several bullets that don’t end with a Closes … reference (e.g., XorFilter<T, THasher>, PooledCeleritySet<…>, BitWriter/BitReader). To avoid a docs-internal contradiction, please make the guidance conditional (only when there’s a tracking issue) or clarify what to do when there isn’t one.

**Keep each entry short and user-facing — a few sentences at most.** State *what* observably changed and *why it matters to a caller*, not how it's implemented. Don't name private fields, list bit-shift/probe steps, or explain JIT/codegen internals — those belong in the PR description or code comments. One tight entry per change: if it needs a paragraph, put the paragraph in the PR body and leave a one-line pointer here. End the entry with `Closes #NNN` — a traceability convention here, since the issue is actually auto-closed by the PR description or commit message that references it, not by the changelog text. (GitHub treats `Closes`/`Fixes`/`Resolves` as equivalent for that; this repo standardizes on `Closes` so the changelog reads consistently.)