Repin Inkling to the commit that compiles against the new base

[danielhanchen]

Repin ggml-org/llama.cpp#25731 (TML Inkling) from 36df1bf4 to 1066edc3.

Why

Run 34108333979 got past every merge for the first time, then failed a later gate:

::error::the pinned PRs merged cleanly and the merged tree does not compile;
fix or drop the pin rather than letting the build matrix find this

src/llama-vocab.cpp:445:13: error: duplicate case value
  445 |   case LLAMA_VOCAB_PRE_TYPE_INKLING:
src/llama-vocab.cpp:321:13: note: previously used here
  321 |   case LLAMA_VOCAB_PRE_TYPE_HY_V4:

This one is more interesting than the previous two repins, because the merge was
clean and still wrong. Both sides appended to the same enum and both took slot 57:

b10830:  LLAMA_VOCAB_PRE_TYPE_HY_V4    = 57,
         LLAMA_VOCAB_PRE_TYPE_SPARK2_5 = 58,
#25731:  LLAMA_VOCAB_PRE_TYPE_INKLING  = 57,

additive_merge.py did exactly what it says it does: the merge base was empty at
that point, both sides only added, so it kept both. That is a pure add/add by
content, and it is still a defect, because the two additions carry the same
explicit value. The union of two case arms that share a value does not compile.

Resolved by keeping upstream's numbering and moving ours: INKLING = 59. Upstream's
values are the ones in released builds, so ours is the one that should move. The
pre-type is resolved from the tokenizer string at load time and is not serialised
into the GGUF, so renumbering does not affect existing model files.

The same commit also takes the llama-model.cpp arm for SPARK2_5 alongside ours
for INKLING, which is a genuine add/add.

Verification

libllama.so, llama-common and test-llama-archs all build clean against the
merged tree, and test-llama-archs exits 0. That is the specific gate that failed
in CI, reproduced locally before pushing.

Worth noting for the merge tooling

Three repins in a row now, all from the base advancing under pinned PRs:

pin	symptom	why the tooling could not fix it
ggml-org#27754	conflict in test-llama-archs.cpp	non-empty merge base, both sides edited a line
ggml-org#24423	conflict in test-llama-archs.cpp	same
ggml-org#25731	clean merge, broken build	pure add/add, but the two additions collide on a value

The third is the one to take seriously: it shows a clean additive merge is not
sufficient evidence of correctness, and the compile gate is what caught it. That
gate is doing real work and should stay. I would not extend additive_merge.py to
understand enum numbering; the cheaper and more honest position is that the compile
check is the backstop, which is exactly how it behaved here.

[chatgpt-codex-connector]

You have reached your Codex usage limits for security reviews. Please try again later.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-07T10:18:29.795488Z	92598b1	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.