[ssrajadh]

Embedder sends truncate_prompt_tokens but not which side to cut, so vLLM falls back to the tokenizer default. For the pooling runner that default became right in vLLM 0.13 (vllm/tokenizers/registry.py). Through 0.12, every runner truncated from the left. On a current vLLM (#3 is on 0.30.0), a state over 2,048 tokens keeps its first 2,048 tokens. state_text puts the question last, so the question is what gets dropped. Training cuts the other way: Recipe.state_ids in train/embed_utils.py keeps the tail.

This PR sends truncation_side: "left" whenever truncate_prompt_tokens is set. The side names what gets cut, so left drops tokens from the start and keeps the last 2,048, question included. The change is two lines in Embedder._fetch.

vLLM accepts truncation_side on embedding requests from 0.18. Older versions allow unknown request fields, so they ignore it instead of rejecting the request, which means 0.13 to 0.17 still cut from the right. If you want that gap closed too, I can add a vllm>=0.18 pin to the vllm extra in this PR.

Testing

I don't have an NVIDIA GPU, so I tested against a Qwen3-8B encoder on MLX that follows vLLM's truncate_prompt_tokens / truncation_side semantics and matches the output reported in #3. The table shows cosine similarity between Embedder.embed() and the same state cut to its last 2,048 tokens:

State	Before	After
2,762 tokens	-0.0006	1.0000
2,757 tokens	-0.0167	1.0000
17 tokens	1.0000	1.0000
12 tokens	1.0000	1.0000

The two long states come from DecisionBench medium, where 139 of the 293 question states are over 2,048 tokens. Shorter states don't change. Neither do the DeepSWE and Terminal-Bench results, because bon_eval.py scores precomputed embeddings. The MLX encoder in #5 always keeps the tail, so with this change the two backends agree on long states.