docs: add CHANGELOG.md following Keep a Changelog

[danbaruka]

Summary

The repository has no CHANGELOG.md. For a Layer-1 chain where validators and integrators need to know exactly what changed between binary releases (consensus-affecting changes, new modules, param defaults, breaking gRPC fields, etc.), a maintained changelog is essential.

Goal

Adopt Keep a Changelog v1.1.0 and seed CHANGELOG.md with entries reconstructed from the existing git history and tags.

Suggested structure

```markdown

Changelog

All notable changes to this project will be documented in this file.

The format is based on Keep a Changelog,
and this project adheres to Semantic Versioning.

[Unreleased]

Added

Changed

Deprecated

Removed

Fixed

Security

State-Breaking / Consensus-Breaking

API-Breaking

[vX.Y.Z] - YYYY-MM-DD

...
```

The two extra sections (State/Consensus-Breaking and API-Breaking) are specific to a Cosmos SDK chain and matter to validators / integrators planning upgrades.

Tasks

• Add CHANGELOG.md at repo root with the template above
• Seed entries from the last few tagged releases by walking git log
• Update CONTRIBUTING.md (see docs: add top-level CONTRIBUTING.md #28) to require a changelog entry under [Unreleased] for any user-visible change
• Optionally wire a CI check (e.g. a simple grep in the PR pipeline) that fails when CHANGELOG.md is unchanged for non-chore/docs PRs

Why this is a good first issue

The template itself is well-defined and writing the initial seed entries is mostly a git log exercise — a great way for a newcomer to learn the project's release history.

[Karry2019web]

/claim

PR #50: #50

[Karry2019web]

/attempt