feat(sc): support multi-reward GDPO rollouts

[tianyi-zhang-02]

What does this PR do ?

Adds end-to-end multi-reward support for GDPO in the Single Controller path. Named reward components now survive native async rollout, JSON payload transport, TQ replay, checkpoint restore, and reward penalties, so GDPO can consume reward/<name> tensors instead of only the summed scalar reward.

The rollout boundary validates component schemas and keeps reward as the canonical scalar sum. GRPO/PPO behavior is unchanged when components are absent.

Issues

Relates to #2625.

Usage

The new functional recipe is:

uv run --locked bash tests/functional/gdpo_single_controller.sh

Validation

Check	Environment	Result
Relevant unit suite	current main; Python 3.13	273 passed
SC GDPO functional	2x H100 NVL 94 GB; Qwen3-0.6B; Megatron + async vLLM; GSM8K; 2 prompt groups x 4 generations	passed one real optimizer step
Runtime assertions	8 completions; 5,422 valid tokens; named reward tensors required by GDPO; metric checks	7/7 passed

The functional run reported loss 4.43e-06, grad norm 0.00323, generation KL 0.000715, and zero masked sequences. It ran from upstream main at 9b25508a3340bffdd8e3a2245ada72279fbc15d6 using nvcr.io/nvidia/nemo-rl:v0.7.0 (driver 570.133.20, CUDA 12.8 compatibility runtime, PyTorch cu130).

Before your PR is "Ready for review"

Pre checks:

• Make sure you read and followed Contributor guidelines
• Did you write any new necessary tests?
• Did you run the unit tests and functional tests locally? Visit our Testing Guide for how to run tests
• Did you add or update any necessary documentation? Visit our Document Development Guide for how to write, build and test the docs.

Additional Information

This change is independent of other open contributor branches.

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.