bug(lock): rich platforms sharing a subdir make PyPI wheel-tag checks nondeterministic

Checks

• I have checked that this issue has not already been reported.
• I have confirmed this bug exists on the latest version of pixi, using pixi --version.

Reproducible example

Commands I ran and their output:

pixi lock

# Run this in multiple fresh processes.
for i in {1..12}; do
  pixi lock --check -vv
  echo "exit=$?"
done

The same freshly generated lock file is accepted or rejected nondeterministically. In one run of 12 checks, 7 passed and 5 failed. A failing check reports:

INFO pixi_core::lock_file::outdated: environment 'default' is out of date because the lock file was solved with system requirements incompatible with the tags on wheel (caio)

pixi.toml:

[workspace]
name = "rich-wheel-repro"
channels = ["conda-forge"]
platforms = [
  "linux-64",
  { name = "linux-new", platform = "linux-64", glibc = "2.38" },
]

[dependencies]
python = "3.14.*"

[pypi-dependencies]
caio = "==0.12.4"

The generated lock correctly contains different wheels for the two target platforms:

linux-64: caio-0.12.4-py3-none-any.whl
linux-new: caio-0.12.4-cp314-cp314-manylinux_2_34_x86_64.whl

pixi info excerpt:

Pixi version: 0.81.0
Platform: linux-64

Issue description

This appears to be a collision in PypiWheelTagsCheck introduced with rich platforms.

PypiWheelTagsCheck::new stores tags in HashMap<Platform, Tags> and inserts them as (pixi_platform.subdir(), tags). Both workspace platforms above therefore use the same Platform::Linux64 key. One tag set overwrites the other, and the retained value varies between processes because the source iteration is hash-map ordered. check also receives only the conda subdir Platform, so it cannot select tags for the original rich platform.

Current code: https://github.com/prefix-dev/pixi/blob/main/crates/pixi_core/src/lock_file/satisfiability/environment.rs#L260-L338

This is related to rich-platform issues such as #6514 and #6770, but those cover platform selection/scoping rather than PyPI wheel-tag satisfiability. #3915 has a similar repeated-lock symptom, but its reported cause is Conda/PyPI package classification and predates rich platforms.

Workarounds are to give same-subdir platforms identical wheel-relevant system requirements, or to use a pre-rich-platform Pixi release.

Expected behavior

A lock file generated by pixi lock should pass every subsequent pixi lock --check. Each locked PyPI wheel should be checked with tags derived from its exact rich platform, not an arbitrary platform sharing the same conda subdir.