Add optional capability_manifest passthrough to checkpoints (#352)

[idoco2003]

What

Adds an optional capability_manifest: passthrough, as offered in #352.

When the training params carry a top-level capability_manifest: block, rl_games copies it verbatim into the saved checkpoint dict (both the A2C/PPO path and SAC). rl_games takes no position on its schema; the block is stored as-is and is a no-op when absent. Consumers read checkpoint['capability_manifest'].

params:
  capability_manifest:        # optional, opaque to rl_games
    command_ranges:
      - { quantity: linear_velocity_x, min: -0.5, max: 1.0, unit: m_per_s }
    terrain_classes: [rigid, deformable]
  algo: { name: a2c_continuous }
  config: { ... }

This lets the limits a policy was trained under travel with the policy, instead of being transcribed by hand downstream and drifting.

Changes

• torch_ext.add_capability_manifest(state, params) — small, schema-agnostic helper (verbatim copy, no-op when absent).
• A2CBase and SACAgent retain self.params and call the helper in get_full_state_weights().
• tests/test_capability_manifest.py — covers present / absent / None-params.

Net diff is +64 lines, no behavior change for existing runs (the block is opt-in).

Context

This comes from URML (an open, Apache-2.0 language for robot intent). The motivating discussion is #352. Prose is AI-assisted and maintainer-reviewed per URML's VIBE.md; happy to adjust naming, placement (top-level params vs config:), or anything else to fit your preferences.

[Denys88]

Thanks @idoco2003 — this is clean and well-scoped. Verbatim, schema-agnostic passthrough, fully opt-in, no behavior change when absent, and no new imports (both agents already import torch_ext). self.params is a new attribute on A2CBase/SACAgent with no collision. Tests cover present/absent/None. Approving.

A couple of optional follow-ups (not blocking — happy to merge as-is):

1. Survive resume. get_full_state_weights() writes the manifest from self.params, but set_full_state_weights() never reads it back. So resuming from a manifest-carrying checkpoint with a config that omits capability_manifest would silently drop it from the next save. Usually fine (the manifest normally lives in the run params across resumes), but if you'd like it to round-trip regardless:

   if self.params is not None and 'capability_manifest' in weights:
       self.params.setdefault('capability_manifest', weights['capability_manifest'])

   in both set_full_state_weights() paths — or just a sentence in the PR confirming the resume behavior is intentional.

2. Scope note. It's emitted from get_full_state_weights() (full checkpoint) only, not the weights-only get_weights() path — which I think is what you want; just confirming that matches the consumer story in #352.

Naming/placement (top-level params: vs config:) looks fine to me as-is.