Prepare 5.1.0 release: drop -SNAPSHOT, finalize CHANGELOG

[bernardladenthin]

Summary

Step 1 of the canonical release procedure. Merge this, then create the v5.1.0 tag and run Publish with publish_to_central=true.

• 5.0.7-SNAPSHOT → 5.1.0 across all four reactor poms via versions:set. Minor, not patch: the b10456 → b10682 range added public API — setKvUnifiedPerSlot, setTensorReadLazy + the new TensorReadLazyMode enum, setCpuFfnLayers, setCpuMoeLayers, setMmprojDevice, and the three setVideo* setters — with nothing removed. The 5.0.7 base is skipped.
• Release dependency examples updated in all four READMEs (13 occurrences): root README.md, llama-langchain4j/, llama-android/, llama-kotlin/.
• CHANGELOG finalized: [Unreleased] → [5.1.0] - 2026-08-29, fresh empty [Unreleased] above it, footer gains the 5.1.0 compare link and [Unreleased] re-points to v5.1.0...HEAD.

Two things worth reading before merging

The snapshot snippet in README.md still says 5.0.7-SNAPSHOT, deliberately. The canonical procedure moves the snapshot example in Step 3, after the release is live. Because this release skips the 5.0.7 base entirely, that line currently names a version that will never be published — it gets repointed to the next snapshot base in the post-release PR. Flagging it so it doesn't read as an oversight.

This follows docs/RELEASE.md, not the previous release. The supplement lists four READMEs carrying release versions; the v5.0.6 prep (b76fb69) touched only two of them. All four are updated here and all now read 5.1.0 with no 5.0.6 left anywhere.

Test plan

• All four poms move in lockstep — verified by parsing each: root own=5.1.0, and llama/llama-langchain4j/llama-kotlin each parent=5.1.0. The children hardcode the parent version (there is no ${revision}), so a missed one fails the reactor with Could not find artifact net.ladenthin:llama-parent:pom:5.1.0. No -SNAPSHOT remains in any pom.
• No 5.0.6 remains in any README; the snapshot line is the only -SNAPSHOT left and is intentional.
• CHANGELOG consistency checked mechanically — released headings, footer compare-links and v* tags are the same set. This is the check that catches the class of defect the sibling repos actually shipped (see below).
• CI green on this branch — pending on this PR. The content is unchanged from the merged b10682 PR (Upgrade llama.cpp to b10682 and bump build tooling #404); this is a version/docs-only commit.

An audit came out of this, landing in workspace

Preparing this release surfaced that the CHANGELOG compare-link footer is the most-missed step, because nothing builds, tests or renders it:

• BitcoinAddressFinder v1.7.0 shipped with no [1.7.0] link at all and [Unreleased] still pointing at v1.6.1 — repaired in its 1.8.0 prep.
• srcmorph v1.1.0 is tagged and released but has no CHANGELOG section at all; the chain jumps 1.0.2 → 1.1.1. Open, recorded in crossrepostatus.md.
• java-llama.cpp and streambuffer are clean — headings, links and tags agree in both.

The hardened checklist, the mechanical headings/links/tags check, and a per-repo table of the version sites that actually drift are now in workspace/workflows/release-process.md.

Related issues / PRs

Follows #404 (llama.cpp b10682 + tooling). Cross-repo release-hygiene findings in the workspace PR of this sweep; BitcoinAddressFinder 1.8.0 is prepared in parallel.

Checklist

• I have read CONTRIBUTING.md and CODE_OF_CONDUCT.md
• My commits follow Conventional Commits
• No security-sensitive changes

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud