[bong-water-water-bong]

This is the unblock for c31. The pin ced49c61 (bumped in by #1260) hands a std::string to a printf-style variadic, so
the engine's own payload build stops:

src/third_party/llama.cpp/src/llama-context.cpp:160:42: error: cannot pass non-trivial object of type 'std::string'
  to variadic function; expected type from format string was 'char *' [-Wnon-pod-varargs]

Clang refuses it and weekly.sh build (HRX toolchain, amdclang++) has not produced a payload since. The line is ours — it
carries the engine #681 comment (the memory-fitting probe has no target context) — and it is the only such instance in
the tree.

fix	1bit-MONSTER/llama.cpp PR #223, commit 198a451c7: model.arch_name() → model.arch_name().c_str(), one token, behaviour unchanged
verification	rebuilt the exact targets that failed under the engine's own toolchain: cmake --build build/hrx/llama --target llama-server llama-bench llama-perplexity compiles the file and proceeds with 0 errors, where it previously stopped on this line
why it could pass elsewhere	GCC's varargs check is laxer than clang's; the engine ships what clang builds

The submodule is repointed at 198a451c7 (the fix commit) rather than a merge commit so this PR is mergeable the moment #223
lands — the commit stays reachable from master either way, and this can be repointed to the merge commit if you prefer that
convention.

After this merges: the payload roll runs (build package), which is what makes the c31 stick possible; the Lemonade bump (#1263)
is still the other, independent gate for c31's content.

[bong-water-water-bong]

Superseded before review: the fork already carries this fix as ab79894d (fork PR #220, merged 11:22 — model.arch_name().c_str(), the same one token), and the engine pin bump is #1267 (e99395e, ced49c61 -> ab79894d). Mine repointed at my own duplicate commit 198a451c7, so it would have been a second route to the same fix. Closing; #1267 is the one to merge. My independent measurements stand and support #1267: the failure is exactly -Wnon-pod-varargs at llama-context.cpp:160, it is the only instance of that class in the tree, and a rebuild of the failing targets under the engine's HRX clang goes from a hard stop to 0 errors with that one token applied.

[bong-water-water-bong]

These two pin bumps are equivalent — measured, so the owner does not have to judge between them.

ced49c61..198a451c7 (this PR, fork branch fix/fit-probe-arch-name-varargs) and ced49c61..ab79894d (#1267, fork branch 1bit/hrx-vulkan-patched, fork PR #220):

	#1265 → 198a451c7	#1267 → ab79894d
commits on top of the pin	1	1
files touched	src/llama-context.cpp	src/llama-context.cpp
the fixed line	__func__, model.arch_name().c_str());	__func__, model.arch_name().c_str());
git show <commit>:src/llama-context.cpp	—	byte-identical to the other
containing branch	fix/fit-probe-arch-name-varargs (topic)	1bit/hrx-vulkan-patched (the tracked line)

So pi-os3's build proof carries over to either pin unchanged ([268/271] Linking CXX executable bin/llama-server, 0 errors, 0 FAILED) — nothing needs re-proving, and I verified the same one-line fix independently with clang++ -19 -std=c++17 -fsyntax-only (error at ced49c61, clean at both candidates).

The only real difference is what the pin tracks: 1bit/hrx-vulkan-patched is the branch this engine has been pinning, so pinning the topic branch would put the pin off the development line and leave fix/fit-probe-arch-name-varargs to rot after the next bump. That is why I opened #1267 against the tracked branch. Merge whichever the owner prefers; if that is this one, I will close #1267 with a note, and if it is #1267 then this can be closed — either way exactly one pin moves.