v0.161.0: Release automation returns: every merge tags and publishes a Release

Last tag: v0.160.0, July 14 — roughly 15 merges have shipped untagged since, while the README described branch-prefix versioning as live. This restores it, redesigned around today's branch protection.

How it works

A small release job in ci.yml (needs: quality-gates, push-to-main only):

1. Finds the PR for the pushed commit (/commits/:sha/pulls). No PR → clean skip — direct pushes like rebuild-trigger commits never release.
2. Reads the latest release tag and bumps it: feature/|feat/ → minor, anything else → patch, version:major|minor|patch labels override.
3. gh release create with the PR title, the PR body as notes, and a compare/ changelog link.

Why tags-only, no bump commit

The old pipeline pushed chore: bump version commits to main. Branch protection now requires passing status checks on anything reaching main — and a commit born inside a workflow run can't have them. Tags sit outside branch protection, so GITHUB_TOKEN with contents: write suffices and nothing fights the protection we just added. Tags/Releases become the version truth; package.json's version stays frozen (this isn't an npm package).

Safety notes

• PR title/body are untrusted text — kept in files, passed via --notes-file, never interpolated into shell.
• needs: quality-gates means a failing build can never get tagged.
• Dry-run of the version math: feature/x → v0.161.0, fix/y → v0.160.1, fix/y + version:major → v1.0.0.

Self-validating

Merging this PR should cut v0.160.1 (branch feat/ is… actually minor — v0.161.0) with this description as its release notes. If a Release appears, it works.

Also updates the README's versioning paragraph from 'paused' to the live behaviour — the last CI claim that was aspirational rather than factual.

---

Full Changelog: v0.160.0...v0.161.0