feat: renderer emits numpy, not torch

[hallerite]

Summary

HF processors return torch by default; multimodal renderers were passing those tensors through to mm_items, which leaked torch into the renderer's data model and forced downstream transport layers (verifiers — which doesn't declare torch as a dep) to handle torch tensors.

Switch all three multimodal processors (Qwen3-VL, Qwen3.5/3.6, Kimi-K2.5) to return_tensors=\"np\". mm_items[i][\"pixel_values\"] and friends now ship numpy arrays. Renderer is torch-free; downstream consumers (vLLM-glue helper in client.py, trainer in prime-rl) convert via torch.from_numpy / torch.as_tensor at their boundary, where torch is already a hard dependency.

Why

Architectural cleanup: the renderer shouldn't know about tensorization. numpy is the lowest-common-denominator format that's already a dep of every realistic consumer (HF, torch, vLLM, jax) and is natively serializable by verifiers' msgpack encoder. This lets verifiers drop its torch handling branch (companion PR opens shortly).

What changes

• Qwen3VLRenderer._process_image — return_tensors=\"pt\" → \"np\"
• Qwen35Renderer._process_image — same
• KimiK25Renderer._process_image — same
• client._build_qwen_vl_features — wrap numpy items in torch.as_tensor before torch.cat / BatchFeature. Torch is already imported here (the vLLM payload encoder is a torch-required code path).
• Bump 0.1.7 → 0.1.8.

Test plan

• Full renderer suite green (980 passed, 49 skipped, 1 xfailed)
• Multimodal byte-parity vs HF processor unchanged (compares input_ids, not pixel arrays)
• Companion verifiers PR drops torch branch from msgpack_encoder and bumps to renderers>=0.1.8
• prime-rl bumps renderers>=0.1.8; trainer-side decode_tensor_payload already handles the encoded wire format identically (numpy/torch source produces the same __torch_tensor__-tagged payload)