Add or update project-wide CHANGELOG and versioning for releases

[bossly]

Introduce or update a structured CHANGELOG and project versioning for organized releases.

Why: Having a clear, continually updated CHANGELOG and using semantic version tags makes it easier for users and contributors to see what has changed, when, and in what version. This is good open source practice and helps with publishing to app stores.

Acceptance Criteria:

• Add a well-structured CHANGELOG.md describing changes per release.
• Start or maintain semantic version tags/releases (e.g., v1.0.0, v1.1.0) with matching entries in CHANGELOG.
• On each merge or release, ensure CHANGELOG is updated and referenced in the PR.
• README links to CHANGELOG and includes a "Releases" section.

Next steps:

• Create or improve a CHANGELOG file.
• Define a versioning policy if none exists (e.g., semver, date-based).
• Document release process steps that reference the CHANGELOG and tag/release flow.