[release] Auto patch tagging + GitHub Release on main (v0.1.x)

[mfittko]

Summary

Stop force-updating existing tags and instead auto-increment patch versions on every update to main (e.g. v0.1.1, v0.1.2, …). Creating/updating minor/major versions remains manual for now.

This should also create a GitHub Release for each auto-created patch tag.

Related / may be a follow-up to #175.

---

Motivation

• Force-moving tags is risky (breaks reproducibility and can confuse deployments).
• Patch versions are a good fit for “every merge to main” fixes.
• We already have OpenAI-enabled tooling for changelog/release notes; reuse that for consistent release entries.

---

Proposal

Auto-patch tagging (on push to main)

• Determine the latest existing tag matching v0.1.*.
• Bump patch by 1 → produce v0.1.<next>.
• Create an annotated tag on the new main HEAD.
• Push the tag.

Auto-release creation

• Create a GitHub Release for the new tag.
• Release notes should be generated via an OpenAI-enabled step (existing tooling or a new small script) using a repo secret (e.g. OPENAI_API_KEY).

Manual minor/major

• v0.2.0, v1.0.0, etc. continue to be created manually for now.

---

Acceptance Criteria

• No existing tags are force-updated in normal operation.
• Every push to main results in exactly one new v0.1.x tag (unless HEAD is already tagged).
• A GitHub Release is created for each auto-generated patch tag.
• Workflow is concurrency-safe (no duplicate tags on concurrent pushes).
• Workflow fails safely (does not create partial releases if tag creation fails).

---

Implementation Notes (suggested)

• Add a GitHub Actions workflow triggered on push to main.
• Use git tag --list 'v0.1.*' --sort=-version:refname to find latest.
• Guard with a lock/concurrency group (e.g. concurrency: release-main) and/or retry on tag push conflicts.
• Use gh release create for the release.
• Use existing changelog generation logic (or a small wrapper) to build release notes.