Conda 23.1 libmamba default solver transition breaking cross-environment reproducibility

Goal

Achieve identical environment resolution on local development machines, CI/CD pipelines, and container builds regardless of whether the Conda installation defaults to the classic solver or to libmamba.

Constraints and uncertainty

Conda 23.1 made libmamba the default solver, altering dependency resolution semantics (stricter conflict detection, different version heuristics, stricter channel‑priority enforcement). Local workstations often retain the classic solver via an older Conda version or an explicit solver: classic entry in .condarc, while production images such as continuumio/miniconda3 ship the new default. Lock files generated by conda-lock, pixi, or conda env export are solver‑specific, so a lock created with the classic solver may not install under libmamba. Channel mixing (defaults and conda-forge) and cross‑platform deployment (Windows → Linux) further amplify divergence. Pinning solver: classic defers the issue but the classic solver is deprecated and will be removed.

What configuration strategy guarantees solver parity across all stages without relying on the deprecated classic solver? How can lock files be made portable between solvers? Which explicit flags or CI/CD steps are required to enforce a single resolver for every conda invocation?