Phase 1: define vime-side RL-Kernel operator adapter boundary

[inaniloquentee]

Summary

Define the vime-side RlkOperatorAdapter boundary used to embed RL-Kernel as an optional operator backend.

Phase

Phase 1: Contract and Telemetry Layer.

Responsibilities

• Add a vime-owned RlkOperatorAdapter protocol/interface and a small construction point for selecting a concrete adapter implementation.
• Keep RL-Kernel imports isolated behind this adapter boundary.
• Expose operator-scoped hooks for capability query, selected-logprob/reference scoring, linear_logp, and lightweight contract/provenance handoff.
• Pass already-resolved vime policy context into the adapter.
• Map vime runtime tensors and metadata into RL-Kernel operator-call inputs without transferring ownership of rollout/training lifecycle.
• Provide a mock or no-op adapter for unit tests.
• Add guardrails showing that production vime code paths do not depend on RL-Kernel's cross-config experiment runner, child-process supervisor, or attempt artifact layout.

Acceptance Criteria

• There is one documented vime-owned adapter boundary for all RL-Kernel-backed operator calls.
• Native vime behavior is unchanged when RL-Kernel modes are disabled.
• Existing and planned Phase 1 code can depend on the adapter protocol or mock adapter without importing RL-Kernel internals directly.
• The adapter receives policy/config context from vime instead of parsing user flags itself.
• Tests cover disabled/no-op adapter behavior and mock successful/unsupported operator behavior at the boundary level.
• Tests or import checks prevent production vime modules from depending on RL-Kernel cross-config execution internals.
• Phase 2 linear_logp integration has a single adapter extension point to implement.