Prebuilt: drop the merged #26841 pin, it now conflicts with the base

[danielhanchen]

Upstream squash-merged ggml-org#26841 (Muse Glimmer) as 62bf73d25, and that commit is an ancestor of the current base tag b10356. The pinned commit 56b32b3e is not an ancestor of anything in the base, so resolve re-applies Muse Glimmer on top of a tree that already has it, and additive_merge.py refuses it, correctly, as one change made twice.

Tonight's nightly stops on this pin. Replaying the resolve merge locally against b10356 with pr-set.json exactly as it is on master:

--- merging ggml-org/llama.cpp#26841 @ 56b32b3e944c461d783604a83beb2cc9b0ca2cf1
CONFLICT (content): Merge conflict in common/speculative.cpp
CONFLICT (add/add): Merge conflict in conversion/muse_glimmer.py
CONFLICT (add/add): Merge conflict in src/models/muse-glimmer.cpp
refused  common/speculative.cpp: merge base is not empty, so at least one side edited existing text
refused  conversion/muse_glimmer.py: both sides add the same line(s), so this is one change made twice
refused  src/models/muse-glimmer.cpp: both sides add the same line(s), so this is one change made twice
ggml-org/llama.cpp#26841 (56b32b3e) does not merge cleanly onto b10356 + the PRs listed before it

The three pins before it merge fine, so this is the only thing in the way.

Nothing is lost by dropping it

b10356 carries the architecture at upstream's final merged state, which is slightly ahead of what we pinned:

git merge-base --is-ancestor 62bf73d25 refs/tags/b10356   -> true
git diff --stat 56b32b3e refs/tags/b10356 -- conversion/muse_glimmer.py src/models/muse-glimmer.cpp
 conversion/muse_glimmer.py  | 2 ++
 src/models/muse-glimmer.cpp | 2 +-

So the base is two lines ahead of the pin, not behind it. LLM_ARCH_MUSE_GLIMMER, src/models/muse-glimmer.cpp, tools/mtmd/models/muse-glimmer.cpp and conversion/muse_glimmer.py are all present in the merged tree with the pin removed, and the built libllama.so and libmtmd.so still export the symbols.

The _doc was misleading

The note said a merged pin becomes an empty no-op once the base contains it, so it could be deleted at leisure. That only holds if upstream takes the PR as a real merge commit. Upstream usually squashes, and a squash shares no history with the pinned commit, so instead of going quiet the pin turns into a hard build failure the day the base tag catches up. The note now says that, and says to delete the entry once a base tag carries the work rather than waiting for it to rot away.

Checks

Merged tree on b10356 with this change: 24423, 25731 and 70 all merge, build completes with CUDA (sm_100), 59 of 60 ctest pass, and test-backend-ops passes separately at 1219/1219 for MUL_MAT and 874/874 for MUL_MAT_ID on CUDA0. The one ctest entry not counted is test-backend-ops itself hitting the 1500s ctest timeout, which is why it was run on its own.