Add CHANGELOG.md and versioning policy

[bradjin8]

Repository: cppa-cursor-browser
Assignee: Brad @bradjin8
Points: 3
Severity: Medium

Problem

The project has no CHANGELOG.md and no documented versioning policy. At version 0.1.0 with a single visible commit (731c1e1 feat: initial implementation (#63)), the README and DEPLOYMENT.md are written at production-deployment level detail, creating an implicit stability signal that the versioning posture does not match. The HTTP API, CLI export script, and /api/set-workspace endpoint are consumed programmatically, but consumers cannot determine the current contract from documentation and will receive no warning when the contract changes. The absence of a version scheme also removes the forcing function that would drive consolidation of duplicated code.

Acceptance Criteria

• A CHANGELOG.md file is created following Keep a Changelog format (keepachangelog.com)
• The changelog includes at least the 0.1.0 release entry with a summary of initial features
• A versioning policy section is added to README.md or a dedicated VERSIONING.md documenting: versioning scheme (semver), stability guarantees for pre-1.0, and what constitutes a breaking change
• pyproject.toml version field is consistent with the changelog
• PR approved by at least 1 reviewer

Implementation Notes

Use the Keep a Changelog format with sections: Added, Changed, Deprecated, Removed, Fixed, Security. For the initial entry, summarize the major feature areas: web UI, CLI export, PDF/HTML/CSV/JSON/Markdown export, CLI agent session support, incremental export, desktop app packaging. The versioning policy should explicitly state that pre-1.0 versions may include breaking API changes in minor releases (standard semver for 0.x). This is particularly important given the "Invisible Contract" compound — consumers need to know the stability posture.

References

• Eval finding: Test 34 (Stability Discipline) — part of the "Invisible Contract" compound (T16+T34)
• Related files: pyproject.toml, README.md