Dynamic LLM/RLHF Trainers: config-driven framework support in the SDK

Narrowed slice of #285 (canonical issue), per the 2026-07-15 community call: **config-driven LLM/RLHF trainers only** — a `ConfigTrainer` carrying a `FrameworkConfig` (framework label + entrypoint command + argument rendering), explicit decorator registration, and TRL (SFT/DPO/GRPO) as the first framework. `BuiltinTrainer` keeps its exact signature; nothing is deprecated.

**Out of scope** (remain under #285): function-driven trainers (`TorchTrainer`, `DeepSpeedTrainer`, ...), `RuntimeConfig`, control-plane extension points.

**Related:** #308 (foundation proposal by @szaher) · kubeflow/trainer#2839 (prior art) · kubeflow/trainer#3508 / kubeflow/trainer#3718 (in-flight GRPO via TRL, for which this provides the SDK surface)

- [ ] KEP PR
- [ ] Phase-1 implementation
- [ ] PoC: TRL path end-to-end on kind

cc @tariq-hasan

Start by reading canonical issue #285, foundation proposal #308, and the cited kubeflow/trainer PRs for existing GRPO and TRL context. Done means producing the KEP PR, completing the phase-1 implementation, and demonstrating the TRL path end to end on kind.

Written by the indexing model from the issue text.