release-please manages versioning, CHANGELOG, and tags from Conventional Commits

## User story

As a **maintainer**, I want **release notes, version bumps, and tags generated from merged commits** so that **cutting a release is "merge the release PR" instead of hand-editing `pyproject.toml`, writing the CHANGELOG, and pushing a tag**.

## Why

CHANGELOG.md has only heading skeletons since 4.0.0. `pyproject.toml` version is hand-edited. Tags are manual. `googleapis/release-please-action` replaces all of this with a single always-open "release PR" against `main` that aggregates Conventional Commits, picks the next version, and updates `CHANGELOG.md` + `pyproject.toml` in one place. Merging the release PR creates the tag, which triggers the OIDC publish.

## Acceptance criteria

- [ ] `.github/workflows/release-please.yml` runs `googleapis/release-please-action` on every push to `main`.
- [ ] `release-please-config.json` exists with `release-type: python`, package path, and CHANGELOG configuration.
- [ ] `.release-please-manifest.json` exists and tracks the current version (initial value `4.0.0`).
- [ ] `pyproject.toml` version is updated by release-please, not by humans.
- [ ] `CHANGELOG.md` is rewritten from the skeleton to match release-please's format (Keep a Changelog compatible).
- [ ] Merging the release PR creates a GitHub Release + tag that the PyPI publish workflow consumes.
- [ ] CONTRIBUTING documents the new flow in one paragraph.

## Out of scope

- Automating the PyPI publish step itself (separate OIDC issue).

## Notes

- Target release: **none — chore** (meta — enables all future release tracking)
- Depends on the Conventional Commits enforcement issue so commit history is actually parseable.
- Depends on the branch-rename issue (`main`).
- Source: modernization assessment §4 (branch-strategy discussion).