Set up release-please for automated versioning and CHANGELOG generation

[x3ek]

Description

Wire up release-please to automate version bumps, CHANGELOG.md generation, and GitHub release tagging from our existing conventional commits.

We already publish conventional commits (enforced by .github/workflows/conventional-commits.yml), so release-please can consume them with no commit-message changes. The piece we're missing is the workflow that watches main, opens a "Release X.Y.Z" PR with the version bump + changelog entries, and on merge creates the git tag + GitHub release.

Why

• 1.0 is on the horizon — we want the release loop running cleanly before tagging 1.0, not after. Cutting 1.0 by hand would lock us into a manual process we'd inevitably skip.
• No CHANGELOG today — pyproject.toml says version 0.1.0, there are no GitHub releases yet, and there's no CHANGELOG.md. release-please backfills all three from the existing commit history on its first run.
• Dogfood-site changelog (Build squishmark.xeek.dev as a self-hosted SquishMark site (marketing + docs + blog) #85) — the changelog page on squishmark.xeek.dev will be a version index that links to each GitHub Release. The release-please outputs we expose here are exactly what a future downstream workflow needs to auto-generate that index, so this setup needs to be CI-friendly out of the gate.
• Consumers — once SquishMark is something people install, semver-tagged releases give them something stable to pin against.

Scope

Core release-please

• release-please-config.json at repo root — single-package config, release-type: python (bumps the version = "..." line in pyproject.toml), changelog-sections configured to match our conventional-commit types (feat, fix, refactor, chore, docs, test, ci)
• .release-please-manifest.json at repo root — seed with current 0.1.0
• Tag format: v{VERSION} (with the v prefix) — predictable for downstream tooling that parses tag names
• .github/workflows/release-please.yml — runs on push to main, opens/updates the release PR
• Workflow permissions — contents: write + pull-requests: write (or use a GH App / PAT if branch protection requires it)
• First-run behavior — the initial release PR will collect everything since 0.1.0 into a single changelog block; that's fine

Set up for downstream automation (no extra implementation, just make sure the seams are clean)

• Workflow exposes the release-please-action outputs (release_created, tag_name, version, body, upload_url) so a future workflow in another repo can workflow_run- or repository_dispatch-trigger off them
• Document in the workflow's top comment which outputs downstream consumers should rely on
• Tag names and release body format stable enough that a future "mirror release list to squishmark-content" workflow can scrape them without bespoke parsing

Polish

• README badge — optional: add a "release" / "latest version" shield once tags exist

Acceptance criteria

• release-please workflow runs on every push to main without errors
• A "Release-please: chore(main): release X.Y.Z" PR exists (or auto-opens) summarizing changes since the last release
• Merging the release PR produces a git tag (v{X.Y.Z} format), a GitHub release with auto-generated notes, and a committed CHANGELOG.md
• pyproject.toml version stays in lockstep with the released tag
• Workflow outputs (release_created, tag_name, version, body) are accessible to downstream workflows — verified by inspecting the workflow run summary
• Conventional-commits CI still passes (no interaction issues with the new workflow)

Out of scope

• PyPI publishing — release-please can trigger a downstream publish workflow on its release event; separate issue if/when we want to ship to PyPI
• Docker image publishing — same pattern, separate issue
• Auto-mirroring releases to the dogfood content repo — a follow-up issue once Build squishmark.xeek.dev as a self-hosted SquishMark site (marketing + docs + blog) #85's Phase 2 establishes what the changelog index page expects
• Multi-package / monorepo configuration — single package, single version

References

• https://github.com/googleapis/release-please-action — official action
• https://github.com/googleapis/release-please/blob/main/docs/manifest-releaser.md — manifest mode docs (recommended over the older single-release mode)

— Claude