server: reuse KV when tools append images

[JordiPosthumus]

Summary

Reuse an exact image-conditioned live KV prefix when a tool appends a new image
strictly after that prefix.

Why

DS4 records the image spans and embedding fingerprints that conditioned a live
checkpoint. Reuse previously required the next request to contain exactly the
same number of images. A vision tool appending a new image therefore discarded
the whole live prefix even when every old token and image was unchanged and the
new image began after the checkpoint frontier.

The prefix is reusable only when:

• every token through the live frontier matches;
• every existing image span and fingerprint matches; and
• every appended span is nonempty, ordered, non-overlapping and begins at or
  after the live frontier.

Changed, removed, moved or replaced images remain cold, as do images inserted
inside already-computed tokens. Protocol reconstruction, text-prefix reuse and
rewinds still require an exact image-state match. Resident-slot routing uses the
same eligibility rule.

Compatibility

Image-conditioned KV remains excluded from the text-keyed disk cache. The
multimodal protections from #916 are unchanged. There is no cache-format,
sampling, model-math, launcher or default change.

Validation

Rebuilt as one commit directly on main
b0a147a7fba6d1a104d047d5a140e9bb4bfc13cd. Unit coverage accepts one and
multiple appended images and rejects edited prefix tokens, changed
fingerprints, removed/moved images, early insertion, zero-length spans,
overlapping spans and incompatible resident slots.

Apple M3 Ultra, Metal default build; CPU is compile/link portability only:

make clean
make -j2
make -j2 ds4_test ds4_agent_test
./ds4_test --server
./ds4_agent_test
make -j2 cpu
git diff --check upstream/main...HEAD

All commands passed on 2026-09-04. Earlier C ASan+UBSan server checks and the
DeepSeek vision image test passed. A real M3 Ultra test used
DeepSeek-V4-Flash-Vision-Exp
MXFP4Experts/F16HC/F16Compressor/F16Indexer/Q8Attn/Q8Shared/Q8Out with its
matching encoder: appending images reused 10,884 and 11,288 live tokens and
evaluated only 231 and 387 new tokens; changing an existing image rebuilt cold.
The original trace had discarded 63,036 valid tokens and spent 142.6 seconds
refilling them.

Matched speed/correctness check

Two mirrored runs per build, M3 Ultra/Metal, 2,048 and 16,384-token text
frontiers, 262,144 allocated context, 4,096 prefill chunk, 64 greedy output
tokens, warmed weights and no MTP:

Frontier	Main prefill	PR prefill	Main generation	PR generation
2,048	630.45	629.24	42.800	42.865
16,384	573.94	573.91	37.430	37.560

All frontier-logit dumps were byte-identical. Every speed difference was below
0.5%; this short engine test is not a server-scheduling, image-throughput or
long-context production guarantee.

./ds4-bench --model "$MODEL" --metal \
  --prompt-file speed-bench/promessi_sposi.txt \
  --ctx-start 2048 --ctx-max 16384 --step-incr 14336 \
  --ctx-alloc 262144 --prefill-chunk 4096 --gen-tokens 64 \
  --warm-weights --csv "$CSV" --dump-frontier-logits-dir "$LOGITS"

Merge coordination: #960 touches the same reuse dispatch. If either lands
first, preserve exact cancelled-retry priority; appended-image eligibility must
not widen protocol-reconstruction matching.