Repin ggml-org#25731 to the commit that merges onto b10369

[danielhanchen]

The nightly prebuild is currently broken. ggml-org/llama.cpp#25731 (TML Inkling) was pinned at 0a9841fa63, and that commit stopped merging when the aged base moved to b10369, which landed mtmd: support pocket-tts (#26871). Both touch tools/mtmd/clip.cpp and tools/mtmd/clip-model.h. The merge loop stops on the first conflict, so this did not just drop Inkling, it dropped the whole mix.

Preflight run that caught it: https://github.com/unslothai/llama.cpp/actions/runs/31593981533

I resolved the conflicts on the PR branch itself, so the pin just moves to the new head.

-  .../pull/25731/commits/0a9841fa63edce1cd252ed6efea713715abb0cf2
+  .../pull/25731/commits/368b24c355d2e2cf3de2f36f71df18cd910357b1

The conflicts

tools/mtmd/clip.cpp, in has_standard_layers. This is an and-chain of "the projector is not X". Inkling adds PROJECTOR_TYPE_INKLING, pocket-tts adds PROJECTOR_TYPE_POCKETTTS_GEN. Resolved to the union, so each side still excludes exactly what it meant to exclude. A model has one proj_type, so adding a disjoint term cannot change the result for anything else.

tools/mtmd/clip-model.h. Empty merge base for the hunk: both sides only append structs. Kept inkling_hmlp_layer from the PR and clip_seanet plus clip_flow_net from upstream. additive_merge.py refuses this one and is right to, since each side also touched the shared closing brace, so it cannot prove the hunk is a pure addition.

The resolution adds no lines of its own. Checked by line multiset against both parents and the merge base: every line either side added is present, and nothing originates from neither.

Verification

Replayed the merge loop from unsloth-prebuilt.yml against the same aged base the preflight resolves, in pr-set.json order:

base: b10369 (6e62ba538)

CLEAN         ggml-org/llama.cpp#24423  daca8075d871
CLEAN         ggml-org/llama.cpp#25731  368b24c355d2
ADDITIVE      unslothai/llama.cpp#70    06d2326acbf5
CLEAN         unslothai/llama.cpp#91    c86ed269986f
CLEAN         unslothai/llama.cpp#95    3db8cb5b2e9b

RESULT: all pins merge onto b10369 in pr-set.json order

Built the resulting mix tree, not just the merge: llama-server, llama-mtmd-cli, test-sampling at -DCMAKE_BUILD_TYPE=Release -DGGML_NATIVE=ON -DLLAMA_BUILD_TESTS=ON. No errors, no warnings.

Ran the tests the PR ships, on the mix: test-llama-archs, test-flash-attn-bias, test-flash-attn-generic-hash and test-chat all pass. test-sampling passes too, which covers #95.

Loaded the real unsloth/Inkling-Small-GGUF mmproj through clip_init on the mix. Projector inkling, vision and audio both up, n_mmproj_embd=4096, and 8 and 2 tensors rather than a standard layer stack, which is what has_standard_layers == false is meant to do. Then built the pre-merge PR head on its own and compared: loader behaviour is identical on the Inkling mmproj and on an ordinary Qwen3.6 mmproj, which still loads its full 334 tensor standard path.