Conda channel_priority strict lacks documented tie-breaking for packages present in both defaults and conda-forge

Conda's channel_priority: strict setting in .condarc is documented to require all packages to originate from the highest-priority channel that provides them. When an environment.yml lists both defaults and conda-forge, and a package version exists in both channels with different build strings, the documentation does not specify whether strict priority mandates accepting the lower build string from the higher-priority channel or whether a higher build string in a lower-priority channel may be selected.

This ambiguity affects reproducibility because the classic solver and the libmamba solver—now the default in recent conda releases—may apply different heuristics during resolution. The defaults channel is also subject to Anaconda's Terms of Service, which can constrain organizational use, while mixing channels without explicit pins risks ABI incompatibilities in compiled scientific packages. Inspecting the channel and url fields in the environment's conda-meta JSON files reveals which channel supplied each package, but without a documented tie-breaking rule the observed selection remains empirical rather than guaranteed.

Which documented constraint governs build-string selection under channel_priority: strict when the same package version appears in both channels? Does the behavior differ between the classic and libmamba solvers in conda 23.x and later? What is the recommended configuration to make this selection explicit and reproducible?