ci: automate releases with Release Please

[KristianP26]

Summary

Automates releases with Release Please: version bumps, CHANGELOG.md, git tags, and GitHub Releases are driven by Conventional Commits, and the existing PyInstaller Windows build attaches its zip to each automated release.

How it works

A single release-please.yml workflow runs on push to main:

• release-please job (ubuntu) runs googleapis/release-please-action@v4, keeping a rolling Release PR up to date (version + changelog). Merging that PR creates the tag (vX.Y.Z) and a GitHub Release.
• build job (windows) runs only when a release was created (needs.release-please.outputs.release_created == 'true'): it checks out the tag, runs the test suite, builds with PyInstaller, and uploads the zip + .sha256 via gh release upload.

Keeping the build in the same workflow avoids the GITHUB_TOKEN limitation (tags/releases created with GITHUB_TOKEN don't trigger separate workflows) — so no PAT is required.

Changes

• Add release-please-config.json (release-type: simple, include-component-in-tag: false → v{version} tags, changelog sections) and .release-please-manifest.json seeded to 1.0.1 (matches existing v1.0.0/v1.0.1 tags).
• Add .github/workflows/release-please.yml; remove the old tag-triggered .github/workflows/release.yml (its build steps are migrated verbatim).
• Update the README "Releases" section; mark the old release-pipeline design doc as superseded.

Notes

• Config/workflow files validated (JSON/YAML); the test suite still passes. End-to-end release behaviour (Release PR, version bump, build) is only observable on main after merge.
• On main the only commit since v1.0.1 is a refactor:, so the first Release PR appears once a feat/fix lands — expected Conventional Commits behaviour.
• The action is pinned to @v4 so the github-actions Dependabot entry keeps it current.