Add component versions, code identity, and compatibility metadata

Problem

Gym can discover agent, model, and resources-server components, but the registry entries do not describe the component version, the code being executed, or the interfaces the component requires and provides.

Without that information, discovery and validation cannot determine whether a selected set of components is compatible. Missing information must not be interpreted as compatibility.

Proposed change

Add one shared component-metadata model with these fields:

• version: the component-owned version, when known;
• code_identity: a structured source, revision, or digest that can identify the implementation used by the component;
• requires: capabilities the component expects from the rest of the resolved workload;
• provides: capabilities the component makes available to the rest of the resolved workload.

The initial capability dimensions must cover:

• model modality;
• agent or harness interface;
• sandbox capability;
• tool protocol;
• session model.

Extend the existing agent, model, and resources-server registry entries to expose this shared metadata. Do not create another registry or a second discovery path. A component must define the data once, and registry, inspection, and validation callers must receive the same values.

Add initial metadata for the components used by the first manifest-backed workloads, including simple_agent, example_single_tool_call, code_gen, mcqa, openai_model, and vllm_model. A runtime-selected policy_model without a concrete model implementation must remain unknown.

Migration behavior

• Existing components without metadata remain discoverable.
• Missing version, code_identity, requires, or provides values are represented as unknown.
• Unknown values must not be converted into implicit compatibility claims.
• Human-readable and JSON inspection must expose the same metadata.

Out of scope

• Enforcing compatibility during validation.
• Deciding which workload components may be replaced.
• Replacing the existing configuration or registry systems.

Acceptance criteria

• Agent, model, and resources-server registry entries expose the shared metadata fields.
• A component defines its metadata in one authoritative place.
• Registry, inspection, and validation consumers observe the same values.
• The initial capability dimensions are represented without hard-coding a closed list of future capability values.
• The components used by the first manifest-backed workloads include metadata.
• Components without metadata report unknown values and remain usable during migration.
• Human-readable and JSON output agree.

Related work

• #1520
• #1582
• #1583
• #2094

Start by tracing the existing agent, model, and resources-server registry entries, then follow their discovery, inspection, and validation consumers. Define the shared metadata once, add initial values for the named manifest-backed components, and verify that human-readable and JSON inspection agree while components without metadata remain discoverable with unknown values.