Automate the post-release version bump

[menjoo]

The README still says 0.1.1 now that 0.1.1 has shipped, because step 3 of RELEASING.md was a list
of commands someone had to remember. This makes it a workflow.

What it does

Actions → Post-release → Run workflow, entering the version just released. It:

1. checks the tag exists — pointing the docs at an unreleased version would send people to a 404
2. runs set-docs-version.py <version> over the README's install snippets
3. runs set-version.sh <next>-SNAPSHOT
4. pushes post-<version> and links to the Open a pull request page in its summary

Simulated end to end against a clone: produces README.md | 8 ++-- and gradle.properties | 2 +-,
which is what #7 did by hand.

Why it anchors on coordinates, not version numbers

set-docs-version.py matches only id("io.github.menjoo.cucumberkmp") version "X" and
io.github.menjoo.cucumberkmp:<module>:X.

Of the fifteen version references in this repository, eight are historical and must never be
rewritten:

Where	Text
release.yml	"0.1.0 was lost to precisely this"
verify-publishable.py	"The 0.1.0 release failed on exactly these rules"
RELEASING.md	"Step 5 exists because 0.1.0 was lost without it"
ARCHITECTURE.md	"0.1.0 does not exist on Central", "the v0.1.0 tag remains as a record"
get-version.sh, RELEASING.md	doc-comment examples

A substitution blunt enough to catch the install snippets would erase the record of the incident
that step 5 of the release workflow exists to prevent. Anchoring on the coordinate cannot reach
prose at all. Verified: the KSP plugin's version "2.3.10" on the line above the plugin id is
untouched, and ARCHITECTURE.md comes out byte-identical.

It also fails loudly if the anchors match nothing, rather than reporting success — otherwise
"documentation is current" and "the patterns broke in a docs restructure" look the same, which is
how a script like this rots unnoticed.

ARCHITECTURE.md is deliberately not rewritten. Its status lines want a human sentence.

Why it doesn't open the pull request

A pull request opened with GITHUB_TOKEN does not trigger workflow runs — GitHub blocks that to
prevent recursion. With CI now required on main, a bot-opened pull request would sit permanently
unable to satisfy its own checks. Opening it yourself is one click and makes CI run normally.

A PAT would buy that click for a long-lived credential, which is the trade RELEASING.md already
declines under "Why not one button".

Notes

• Python rather than bash, matching verify-publishable.py: anchored regex with capture groups and
  per-line reporting is awkward in shell.
• Hardening carried over from Escape feature-file text in generated code, harden CI #10: contents: write only, inputs reach bash through env, actions
  SHA-pinned.
• Also retargets the Release workflow's "Next:" summary at this workflow.

Ordering

Merge after #11. The first real use is 0.1.2's post-release step.