the qwen3vl projector bug is upstream and fixed; bump the vendored llama.cpp

Our llama-cpp-python 0.3.30 vendors llama.cpp e3a74b299 (2026-06-16). The fix for
this exact failure landed five weeks later:

    b4aa7dd47  mtmd : use align_corners for qwen3vl vision position embedding
               interpolation  (#25781, 2026-07-21)

0.3.36 vendors 0c1e57098 (2026-10-01), which contains it. Wrong position-embedding
interpolation makes the vision features spatially meaningless, which is why
Qwen3.8-27B described every picture identically rather than merely badly, and why
a gemma4v projector -- a different graph, untouched by that bug -- read the same
images correctly through the same pipeline.

Everything measured fits: the projector pairs correctly (projection_dim 5120 =
hidden_size 5120), loads, and injects tokens the model notices, since it says so
when no image is sent; two publishers' conversions fail identically because the
defect is in the consumer not the artifact; and the image-token floor is
irrelevant -- tested at 1024 and at 0, byte-identical answers both times.

The bump only takes effect on a rebuild (REBUILD_LLAMA=1), and it must stay a
local source build: the CMAKE_ARGS carry -DGGML_CUDA=ON -DGGML_VULKAN=ON
-DGGML_RPC=ON together, and a PyPI wheel has at most one backend. Until a rebuild
runs, mmproj stays off the qwen38 cards and vision goes to gemma-4-31B-heretic.

Also records the method failure, because it cost most of the investigation: three
conclusions were drawn from reading headers and code and all three were wrong.
The floor was dismissed with "the symptom predates it" -- which was never
checked, and could not have been, since the floor is applied automatically
whenever the projector type matches. Two projectors were then compared while the
one variable this repo introduced was held constant in both.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014T3rZozi1Ehk96NG1WesgC

codai/__init__.py

@@ -16,7 +16,7 @@
 
 # Canonical product version for CoderAI — single source of truth. Both the API
 # metadata and the admin web UI read from here.
-__version__ = "0.5.50"
+__version__ = "0.5.51"
 __tagline__ = "Complete orchestration, distribution and escalation of remotizable advanced inference."
 
 # Configure the CUDA caching allocator BEFORE torch is imported anywhere.

docs/serving-a-model-this-box-cannot-hold.md

@@ -172,6 +172,38 @@ is correct at two different model sizes, and Qwen3.5's OWN vision tower is
 correct when transformers runs it instead of llama.cpp — so it is not the model,
 not the family, and not our pipeline.
 
+## The actual cause: our llama.cpp predates the fix
+
+```
+our build (0.3.30)  vendors llama.cpp e3a74b299   2026-06-16
+the fix             b4aa7dd47  "mtmd : use align_corners for qwen3vl vision
+                    position embedding interpolation" (#25781)   2026-07-21
+0.3.36              vendors llama.cpp 0c1e57098   2026-10-01   <- contains it
+```
+
+Five weeks. Wrong position-embedding interpolation makes the vision features
+spatially meaningless, which is why the output is constant rather than merely
+wrong, and why `gemma4v` -- a different graph, untouched by that bug -- reads the
+same images correctly through the same pipeline.
+
+Everything observed fits: the projector pairs correctly, loads, and injects
+tokens the model notices (it says so when there is no image); two publishers'
+conversions fail identically because the defect is in the consumer, not the
+artifact; and the image-token floor is irrelevant, confirmed by testing with it
+at 1024 and at 0 and getting byte-identical answers.
+
+`packaging/linux/Dockerfile.update-llama` is bumped to 0.3.36 for this reason.
+It takes effect only on a rebuild, so until one runs, `mmproj` stays off the
+qwen38 cards and vision goes to gemma-4-31B-heretic.
+
+One method note, since it cost most of the investigation: three conclusions were
+drawn from reading headers and code, and all three were wrong. The floor was
+dismissed with "the symptom predates it" -- never checked, and it could not have
+been, because the floor is applied automatically whenever the projector type
+matches. Two projectors were compared while the one variable introduced by this
+repo was held constant in both. What settled it was varying one thing at a time
+against a known-good control.
+
 ## If you try a newer llama.cpp, do NOT pip install it
 
 Six versions of llama-cpp-python have shipped since the one we run (0.3.30 vs

packaging/linux/Dockerfile.update-llama

@@ -20,7 +20,15 @@ ARG CUDA_BUILDER=nvidia/cuda:13.0.2-devel-ubuntu24.04
 FROM ${CUDA_BUILDER} AS llamabuild
 ARG PYTHON_VERSION=3.13.5
 ARG PBS_RELEASE=20250612
-ARG LLAMA_CPP_PYTHON_VERSION=0.3.30
+# 0.3.30 vendored llama.cpp e3a74b299 (2026-06-16), five weeks BEFORE
+# b4aa7dd47 "mtmd : use align_corners for qwen3vl vision position embedding
+# interpolation" (#25781, 2026-07-21). Without that fix a qwen3vl projector
+# loads, injects its image tokens, and describes every picture identically --
+# measured on zeiss 2026-10-30 across two publishers' conversions, with and
+# without an image-token floor, while a gemma4v projector read the same images
+# correctly through the same code. 0.3.36 vendors 0c1e57098 (2026-10-01), which
+# contains it. See docs/serving-a-model-this-box-cannot-hold.md.
+ARG LLAMA_CPP_PYTHON_VERSION=0.3.36
 # SASS for every card the release may meet (Ampere → Blackwell). sm_86 alone
 # is what the local box needs; the GitHub release is for anyone.
 ARG CUDA_ARCHS="80;86;89;90;120"