[WS5] Map vime architecture and RL-Kernel hook points

[inaniloquentee]

Part of #83 · coordinates with WS3 vLLM rollout integration probing

Map vime's architecture and identify the concrete places where RL-Kernel operators could be injected. Confirm whether vime is built on slime's training stack with vLLM (+ vllm-router) as the rollout backend, then trace where logprob / loss / sampling operators are invoked on both rollout and training sides.

Planned:

• Architecture map: vime repos/modules, launch flow, process boundaries, and where slime owns the training dataflow.
• Rollout-side map: vLLM / vllm-router path for sampling and logprob, token ownership, batching/padding behavior, and available extension points.
• Training-side map: Megatron/slime path for logprob, loss, reductions, and where framework-level alignment logic runs.
• Hook-point matrix: operator name, rollout/training side, current callsite, candidate RL-Kernel op, required tensor contract, expected change surface, and whether the hook is public/stable/private.
• WS3 handoff note: record the shared vLLM rollout-path findings so WS3 and WS5 do not duplicate probing work.

Non-goals: no RL-Kernel code injection, no upstream vime/slime/vLLM changes, and no real vLLM == Megatron alignment claim. This issue produces the map and hook inventory only.

Can start in W1. Depends only on access to the target vime/slime/vLLM source and a runnable environment.

[inaniloquentee]

This is the PR: #125