Add a task discovery API for backend combinations

[AntoineRichard]

Description

The Gym registry is currently walked in two places that answer two different questions:

• tools/environ_docs.py reads what a task declares. That is what the environments.rst tables publish.
• Nothing reports what actually resolves.

The gap is not theoretical. A combination can be documented while being impossible to run — that is how the AnymalC-Direct rows advertised presets the task does not have (fixed by hand in #6914). Because CI never runs update_environments_rst.py --check, nothing catches that class of drift.

This adds tools/task_discovery.py:

discover_tasks(resolve=False)   # what each task declares - fast
discover_tasks(resolve=True)    # build each combination + run the runtime validator

Resolved mode is the useful part: the cross product is not all legal. OVRTX is kitless and cannot share a process with Kit physics, so isaacsim_physx + ovrtx is declared yet unusable. Discovering that costs one config resolution; discovering it on a GPU costs a whole benchmark run.

Automatic selectors are reported separately

physics=physx (PhysxAutoCfg) resolves to OvPhysX kitless and to Isaac Sim PhysX under Kit. renderer=rtx (_AutoRtxRendererCfg) behaves the same way. A selector and the backend it resolves to are therefore the same run, which is why the tables already say:

physics=physx is also a valid automatic selector [...] The tables list only concrete backends so that each row identifies the runtimes it supports.

That knowledge currently lives in three places — the docs prose, the filtering inside environ_docs, and a downstream benchmark dispatcher — and they have already drifted apart. DiscoveredTask.selectors exposes it as data instead:

concrete = tuple(n for n in t.declared["renderer"] if n not in t.selectors.get("renderer", ()))

Detected by config type, not by name, so adding a selector upstream needs no edit here. Currently finds physx on 50 tasks and rtx on 7.

Whether a selector is redundant depends on how the caller launches, so discovery reports both and leaves the policy to the caller.

Equivalence with the current docs walk

resolve=False was compared against collect_environment_doc_rows() across the whole registry:

task_discovery = 127   environ_docs = 127
only in task_discovery: []
only in environ_docs  : []
field mismatches      : 0     (RL libraries, physics, renderer, domain presets)

The one apparent RL-library difference is environ_docs' own RL_LIBRARY_OVERRIDES table, applied downstream where it belongs.

Scope, and what is deliberately not here

This lands the module only. Nothing in-repo consumes it yet — that is intentional, so the equivalence above can be reviewed on its own before working doc generation is touched. Planned follow-ups in this PR:

1. collect_environment_doc_rows() delegates to discover_tasks(resolve=False), keeping apply_rl_library_overrides and _physics_names_for_docs where they are, with update_environments_rst.py --check proving environments.rst is byte-identical.
2. A CLI, and optionally a --check mode that reports declared-but-unresolvable combinations so CI can fail on doc drift.

Two things I would like reviewer input on:

• _selector_names loads the env config a second time (once via enumerate_task_presets, once via collect_presets), roughly doubling declared-mode cost. Reusing a single walk means duplicating _bucket_variants_by_target; exposing the walked configs from preset_cli would be cleaner but widens this PR.
• Home. tools/ matches environ_docs.py, but if this should be a supported API for out-of-tree consumers, source/isaaclab_tasks/isaaclab_tasks/utils/ may be the better place.

Type of change

• New feature (non-breaking change which adds functionality)

Checklist

• I have run the pre-commit checks with ./isaaclab.sh --format
• I have added tests that prove my fix is effective or that my feature works
• I have added a changelog fragment under source/isaaclab/changelog.d/
• Consumer wiring (see Scope) — follow-up commits in this PR