Every image sent to a GGUF vision embedder answered 500. Caught on live traffic
by the 5xx logging added hours earlier, which named it in one line:

    [radeon] mtmd_tokenize: error: number of media markers in text (0) does not
             match number of bitmaps (1)
    [radeon] [http] 500 on POST /v1/embeddings:
             'Embedding failed: mtmd_tokenize failed (2)'

`mtmd_input_text` carries a `text_len` beside its `c_char_p`, and the struct was
built with the constructor form, which leaves it at 0. Measured in the
container: that form gives text_len == 0 for a 38-byte prompt, the field-by-field
form gives 38. llama.cpp read a zero-length prompt, found no media marker in it,
and refused the bitmap it had been handed. The marker was never the problem --
mtmd_default_marker() is b'<__media__>' and _prompt() interpolates it, both
verified against the running engine, and both were suspected first.

Built field by field now, exactly as llama_cpp's own chat handler does it, which
also keeps a NAMED reference to the encoded bytes. That second half matters on
its own: `text` is a c_char_p, so a temporary is free to be collected while the
struct still points at it -- a latent defect in the same two lines that would
have been intermittent rather than total.

Verified against the running server afterwards: image-only, text-only and
text+image to gme-Qwen2-VL-2B-Instruct-Q4_K_M all return 1536-d embeddings.
Each of the two image cases was a 500 before.

The request log now reports the image count. Its absence is why the search
started in the wrong place: `model=gme-… inputs=4 chars=84` reads as a text-only
request, because _summarise logged `input` and never `image`, so a failure on
the IMAGE path looked impossible. Counts only, no content, like the rest of
that line.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014T3rZozi1Ehk96NG1WesgC