Upgrade llama.cpp to b10682 and bump build tooling

[bernardladenthin]

Summary

• llama.cpp b10679 → b10682. No project-source change was required, and this range cannot require one — that is a checked result, not an assumption. The whole delta is ten files (575 insertions / 59 deletions, 53 KB), so it stays well under the runbook's 100 KiB chunking threshold and was taken in one step: Metal flash-attention vec tunings for M1 Max (ggml-org/llama.cpp#27932), a Vulkan mul_mat_id change that pads K rather than N (ggml-org/llama.cpp#27925), the Snapdragon Windows SDK scripts (ggml-org/llama.cpp#27903), documentation, and one upstream test this project never compiles. Not one changed file is on the priority review list, and the 42 files the eight local patches touch have an empty intersection with the range's changed-file list — so all eight apply unchanged and 0001 stays at its 37-file form.
• A misleading test diagnostic fixed, found by this bump (see below).
• Build tooling bumped and NullAway aligned across the siblings: nullaway 0.13.8 → 0.14.0, spotless-maven-plugin 3.10.0 → 3.10.1, palantir-java-format 2.96.0 → 2.97.0, pitest-maven 1.25.9 → 1.30.0, logcaptor 2.12.6 → 2.12.7.

The diagnostic defect this bump exposed

The first (incremental) local run of NativeLibraryLoadSmokeTest.nativeBuildInfoMatchesPinnedVersionConstant failed with

Linked build-info "b10682-5ea1b124e" must start with the pinned tag "b10679-"

even though every pin site already read b10682 and the freshly linked library was correct. The assertion message names exactly one cause — a GIT_TAG/constant drift — which is the one that did not apply, so it points the reader at the wrong place.

LLAMA_CPP_VERSION is a static final String, i.e. a compile-time constant that javac inlines into every referencing class, this test included. An incremental build recompiles the constant but not the test class, whose own source did not change, so the previous literal survives in the test bytecode. Confirmed rather than assumed: strings on the .class showed it was from the earlier build and still carried b10679-. A clean build is green.

The message now names both causes, says which one the shown tag distinguishes, gives the fix, and records that CI always builds from a clean checkout and cannot hit it. Same class of defect as the CI crash-log text that asserted an abort it could not observe: a diagnostic that is confidently wrong costs more than none at all.

Tooling: what was deliberately not taken

versions:display-dependency-updates also offers these; each is refused on purpose, recorded here so a future Dependabot PR does not quietly undo the decision:

• jqwik 1.9.3 → 1.10.1 — forbidden by workspace/policies/jqwik-prompt-injection.md. 1.10.0 added a deliberate prompt-injection string to test stdout, and upstream states the library "is not meant to be used by any 'AI' coding agents at all." The pin is the decision, not an oversight.
• maven-compiler/jar/source/resources 4.0.0-beta-*, surefire 3.6.0-M1, slf4j 2.1.0-alpha1, log4j 3.0.0-beta2 — pre-releases the plugin offers because it does not filter by qualifier.
• maven-gpg-plugin 3.2.8 → 1.5 / 1.6 / 3.0.1 — regressions, an artifact of version ordering.

nullaway is an alignment, not merely a bump: streambuffer had already merged a Dependabot bump to 0.14.0, so the four repos had silently stopped being identical while crossrepostatus.md still listed 0.13.8 as canonical for all of them. That row is corrected in the workspace PR of this sweep.

Test plan

• Affected unit / integration tests pass locally. Fresh cmake -B build-b10682 -DBUILD_TESTING=ON through the real FetchContent PATCH_COMMAND — fail-loud, and it pins its stamp to the checked-out commit, which is why a fresh build directory is mandatory. Configure reported ggml commit: 5ea1b124e (= b10682) and applied all 8 patches clean. Release build clean, ctest 520/520. Java 1476 run / 0 failures / 17 model-gated skips, NativeLibraryLoadSmokeTest 4/4 with 0 skipped — including the pin cross-check against the freshly linked libjllama.so. mvn spotless:apply produced no changes.
• Tooling verified with real exit codes (a first attempt put rc=$? after a pipe and measured tail, so it reported success unconditionally; redone): spotless:check OK and clean compile OK. Those are the two checks that matter — palantir 2.97.0 would fail spotless:check if the formatter's output had changed, and nullaway 0.14.0 would fail the compile under -Werror if its new release flagged existing code.
• CI is green on this branch — pending on this PR. Note that pitest 1.30.0 is five minor versions and the value/args/exception/json gate is at mutationThreshold 100; a local mutationCoverage run was still in flight when this PR was opened, so CI is the authority on that one. If it goes red, the pitest bump alone is what to revert — nothing else here depends on it.
• Docs / CHANGELOG updated — CLAUDE.md, README.md, CHANGELOG.md, docs/history/llama-cpp-breaking-changes.md (inventory + verification row for b10679–b10682).

Related issues / PRs

• ggml-org/llama.cpp#27932 — Metal FA-vec tunings for M1 Max
• ggml-org/llama.cpp#27925 — Vulkan mul_mat_id pads K rather than N
• ggml-org/llama.cpp#27903 — Snapdragon Windows SDK setup

Part of a cross-repo sweep landing the same tooling alignment in BitcoinAddressFinder, srcmorph, streambuffer and BroomCabinet, with the canonical matrix corrected in workspace.

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