Backfill changelog and tighten release-note policy

Reworked `CHANGELOG.md` into a Keep a Changelog-style release history backfilled from published GitHub releases (starting at 1.6.25), added a structured `Unreleased` section, and linked each version to release/comparison URLs. Updated contributor guidance and the PR template to require concise user-facing changelog notes (or justification when not needed), and added a direct changelog link in the README navigation to make release history easier to find.

.github/PULL_REQUEST_TEMPLATE.md

@@ -19,6 +19,7 @@
 - [ ] I have performed a self-review of my own code
 - [ ] I have commented my code, particularly in hard-to-understand areas
 - [ ] I have made corresponding changes to the documentation
+- [ ] I have added a concise user-facing note under `Unreleased` in `CHANGELOG.md`, or explained why this change needs no release note
 - [ ] My changes generate no new warnings
 - [ ] I have added tests that prove my fix is effective or that my feature works
 - [ ] New and existing unit tests pass locally with my changes

CONTRIBUTING.md

@@ -332,6 +332,25 @@ Before submitting, test your changes:
 - [ ] No console errors or warnings
 - [ ] Tested on multiple browsers (for frontend)
 
+### Changelog and release notes
+
+For user-facing changes, add a short note to `CHANGELOG.md` under `Unreleased`.
+Use `Added`, `Changed`, `Deprecated`, `Removed`, `Fixed`, or `Security`, with
+each category appearing only once per version. Explain the behavior users gain
+or the problem fixed; include upgrade actions for incompatible changes. Internal
+refactors and test-only changes do not normally need an entry.
+
+When preparing a stable release, move only the changes included in that release
+into a `## [X.Y.Z] - YYYY-MM-DD` section, newest first. Verify the version against
+the release tag and the date against its actual UTC publication date; do not
+invent dates for untagged development versions. Add the release link and a
+comparison with the previous published panel tag. Keep subsequent development
+work under `Unreleased` and update its comparison base. GitHub release notes
+should include that version's summary or link directly to its changelog section.
+
+Check the notes against the release's commit range before publishing. A version
+bump alone is not evidence that a release was published.
+
 ### Review Process
 
 1. Maintainers will review your PR

README.md

@@ -36,7 +36,7 @@ English | [Español](docs/README.es.md) | [中文版](docs/README.zh-CN.md) | [P
 
 <br>
 
-[Quick Start](#-quick-start) · [Screenshots](#-screenshots) · [Features](#-features) · [Architecture](#-architecture) · [Roadmap](#-roadmap) · [Docs](#-documentation) · [Contributing](#-contributing) · [Discord](#-community)
+[Quick Start](#-quick-start) · [Screenshots](#-screenshots) · [Features](#-features) · [Architecture](#-architecture) · [Roadmap](#-roadmap) · [Changelog](CHANGELOG.md) · [Docs](#-documentation) · [Contributing](#-contributing) · [Discord](#-community)
 
 </div>