extras: robomimic and LIBERO on MuJoCo 2.3.7, mujoco on MuJoCo 3, as declared conflicts; lock current

[tactino]

The docs audit found uv.lock out of date (uv lock --check fails), and relocking it would have gone wrong. Resolving it per extra showed why:

extra	before (current lock, or a plain relock)	after
mujoco	MuJoCo 3.6.0, but a relock turns it into 2.3.7	3.6.0
robomimic	lock holds robomimic 0.3.0 though pyproject asks for 0.4.0	0.4.0, robosuite 1.4.1, MuJoCo 2.3.7
libero	robosuite 1.4.1 on MuJoCo 3.6.0, which robosuite 1.4.1 rejects	robosuite 1.4.1, MuJoCo 2.3.7, robomimic 0.3.0

The libero row now matches the client environment E42 recorded on qz103: robosuite 1.4.1, MuJoCo 2.3.7 and robomimic 0.3.0.

• [tool.uv] conflicts declares mujoco against robomimic and against libero. The comment in pyproject.toml already said they belong in separate environments; uv now knows it too, and resolves each on its own MuJoCo. Asking for both gives Extras mujoco and robomimic are incompatible with the declared conflicts.

• libero pins mujoco==2.3.7.

• uv.lock is regenerated with uv 0.9.8, and uv lock --check passes.

• The README gives two install groups instead of one command for all six extras:

  • mujoco, classic, atari and d4rl together.
  • robomimic or libero, each in its own environment. They resolve together, but robomimic would move to 0.4.0, and LIBERO has only run on 0.3.0.

  The old command could not produce a working environment. The README records the correction.

The install without extras, which CI tests, resolves to the same versions as before. Slimming that default install (pandas unused, imageio's ffmpeg only for recording, per E45) is a separate PR.

Not included: a uv lock --check step in CI, before uv sync --frozen. --frozen never asks whether the lock matches pyproject.toml, which is how this went unnoticed. My token cannot change workflow files, so that step is left for a follow-up.