[WS5] RL-Kernel to vime integration design doc

[inaniloquentee]

Part of #83; depends on #118; feeds the P1 full-integration effort

Produce the "RL-Kernel to vime integration" design doc. The goal is to define a non-intrusive integration path and positioning statement before any broad implementation work starts.

Planned:

• Integration design doc covering insertion points, expected tensor/API contracts, lifecycle, ownership boundaries, and rollout/training-side responsibilities.
• Non-intrusive activation path: custom op / optional backend / config flag shape, with pure vime inference and native RL paths unaffected when disabled.
• Change-surface estimate: what can live entirely in RL-Kernel, what requires vime/slime adapter code, and what would need upstream vLLM/vllm-router changes.
• Positioning statement: RL-Kernel provides operator-level consistency beneath vime's framework-level alignment; complementary rather than competing.
• Risk and fallback section: private API reliance, version pinning, missing extension points, unsupported hardware, and how the PoC should fail safely.

Non-goals: no production integration, no vime upstream PR, and no claim that this closes real-engine train-inference consistency. WS5 scopes the path; WS3/P1 own the full real-engine integration.

Start after the hook-point inventory in #118 is usable.

[inaniloquentee]

This is the PR: #126