llama-context : sync pending async copies before clearing embd_seq

[o7si]

Overview

Fixes #25654

Pooled embeddings (--pooling last/mean/cls) are written into the per-sequence embd_seq buffers with an asynchronous backend copy. embd_seq is freed at the start of the next decode() / encode() (both clear it) and by the destructor, without waiting for the copy.

Without that synchronization, the copy can complete after the buffer is freed, writing into freed memory and corrupting the allocator's metadata, which aborts the process on the next allocation:

llama-server(89298,0x1f9140c00) malloc: Incorrect checksum for freed object 0x13c888c00: probably modified after being freed.
Corrupt value: 0xc09339813e8a7d6f

This PR synchronizes before embd_seq is cleared in decode() / encode(), and in the destructor before the output buffers are freed.

Requirements

• I have read and agree with the contributing guidelines
• AI usage disclosure: YES

[CoruNethron]

Tested according to #25654 , the issue is not reproducible anymore in my setup.
Thank's for your effort, @o7si ; Fast and precise. 👍

[o7si]

Tested on macOS (Apple M5, Metal) with Qwen3-VL-Embedding-2B (Q6_K + f16 mmproj). Following the repro from the issue (#25654), I hammered the endpoint with sequential and concurrent image embedding requests, no abort:

cat example.jpg | base64 > ex.b64

REQ='{"input":[{"prompt_string":"<__media__>","multimodal_data":["'$(cat ex.b64)'"]}]}'

# 60 sequential requests
for i in $(seq 1 60); do
  curl -s -X POST "http://127.0.0.1:8080/v1/embeddings" \
    -H "Content-Type: application/json" -d "$REQ" \
    -o /dev/null -w "seq $i: %{http_code}\n"
done

# 8 concurrent requests
for i in $(seq 1 8); do
  curl -s -X POST "http://127.0.0.1:8080/v1/embeddings" \
    -H "Content-Type: application/json" -d "$REQ" \
    -o /dev/null -w "conc $i: %{http_code}\n" &
done
wait

All requests return 200 with valid embeddings and no abort.

[CoruNethron]

@o7si ,FYI, for this particular usecase it might be helpful to iterate different images for testing, cause otherwise server somehow returns cached response, without re-evaluating inference.
I tested with different images sequence and see no issues with your patch anyway.