pixi installs wrong version of a git depency with version collision with pypi

[crusaderky]

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

1. pick any python project on github whose version in setup.py must be manually updated
2. clone and fork a new branch
3. add a line # hello world! to __init__.py or some other file that will get installed by pip
4. push the new branch
5. Verify that pip install git+https://github.com/yourname/yourproject.git@yourrev still reports the latest published version; e.g. there's no auto version bump on each git commit
6. create a new project and reference your fork:

[tool.pixi.pypi-dependencies]
yourproject = { git = "https://github.com/yourname/yourproject.git", rev = "yourrev" }

7. pixi update
8. inspect pixi.lock and observe that it correctly points to your git fork
9. pixi run <something>
10. inspect .pixi/envs/yourenv/lib/python3.13/site-packages/yourproject/ and open the file you marked with the hello world. Observe that the change is not there.

Issue description

My pyproject.toml:

[tool.pixi.pypi-dependencies]
# DNM main plus #205, #207, #211
array-api-compat = { git = "https://github.com/crusaderky/array-api-compat.git", rev = "9761bf2c2790416e3c117ed9f64407525b4a3498" }

After I run pixi update, pixi.lock correctly points to my desired git fork:

- pypi: git+https://github.com/crusaderky/array-api-compat.git@9761bf2c2790416e3c117ed9f64407525b4a3498

However, .pixi/envs/tests/lib/python3.13/site-packages/array_api_compat contains the latest published version of the package on pypi.

The problem was that the package above has a manually-updated version in setup.py, which hadn't been changed since the latest release on pypi.

Workaround

Manually update the version in your git tip's setup.py / setup.cfg / pyproject.toml to be higher than the latest released version

Expected behavior

pixi should respect my pyproject.toml, and should definitely respect its own pixi.lock.