feat: add BaseMultiRewardVerifyResponse for shared multi-reward contract

[init-nikhil]

Define reward_components once in nemo_gym as the trainer-agnostic producer-side contract, and migrate example_tool_call_multireward to inherit it.

TODO: I'm updating docs to reflect these changes.

Closes #1664

[init-nikhil]

Making the reward_components field required

In the case of a MultiRewardVerifyResponse, I think we should keep the reward_components field required (non-optional).

if you subclass MultiRewardVerifyResponse, you're saying this env is multi-reward so reward_components should always be there
optional means trainers still have to handle the missing case, which defeats the point of a shared contract
opt-in is at the class level (MultiRewardVerifyResponse vs BaseVerifyResponse), not "maybe this field is set"

[init-nikhil]

Not providing sum(reward_components.values() as the default reward

I don't think we should implicitly aggregate with sum. The aggregation strategy is part of the reward/task definition, and an unweighted sum isn't the common case in modern LLM post-training. Making sum the default bakes in an opinionated choice that will be wrong for many workloads.

verify() in each env definition will specify how to aggregate rewards and if that's not enough, advanced trainer integrations can choose to do custom logic using the reward components.

[ananthsub]

LGTM, but please also update the docs in fern/versions/latest/pages/api-reference/index.mdx and fern/versions/latest/pages/build-verifiers/multi-reward-verification.mdx

so that BaseMultiRewardVerifyResponse is documented for users too

[github-actions]

🌿 Preview your docs: https://nvidia-preview-feat-base-multi-reward-verify-response.docs.buildwithfern.com/nemo/gym

Here are the markdown pages you've updated:

• nemo/gym/api/reference/api-reference
• nemo/gym/build-verifiers/multi-reward-verification

[init-nikhil]

Aggregate metrics (and reward profiler?) go off of top level numeric fields in BaseVerifyResponse. I think we want these updated to go into the reward_components dict when its present?

@ananthsub lmk if that makes sense to you and I'll add that support in a follow on PR.

[init-nikhil]

@ananthsub just realized that if I make changes after a PR approval, it'll need approval again, so re-requesting :)