CHANGELOG + deprecation policy (stability signaling)

[AuraMindNest]

Problem

Integrators and operators had no single place to see version history or what stability guarantees apply to the Boost endpoint HTTP API, format registration, and settings hooks. GitHub Releases also used auto-generated notes instead of curated, version-aligned release documentation.

Acceptance Criteria

• CHANGELOG.md exists, follows Keep a Changelog format, and documents the initial 1.0.0 release with an [Unreleased] section for future entries
• A deprecation policy section defines SemVer rules, a one-minor-release notice period for breaking changes, and the public integration surface (HTTP API, WEBLATE_FORMATS, documented env vars)
• Manual release.yml extracts the matching ## [version] section from CHANGELOG.md and uses it as GitHub Release notes (with Weblate build version appended)
• README.md links to the changelog and deprecation policy in the documentation table and notes that release notes come from CHANGELOG.md

Implementation Notes

• Release workflow uses a Python inline script with regex to slice the changelog section for PLUGIN_VERSION from pyproject.toml; the job fails if no matching section exists
• Deprecation policy distinguishes guaranteed public surfaces from internal boost_weblate.utils.* modules and undocumented env vars
• gh release create switches from --generate-notes to --notes-file populated from the extracted changelog section

References

• CHANGELOG.md
• .github/workflows/release.yml
• README.md