Don't constrain build-system.requires with our dependency-versions

[joerick]

Fix #2570.

Don't constrain the versions installed during the package build using dependency-versions. See #2570 for full discussion. AI summary of the change below

---

This change stops cibuildwheel's dependency-versions from being applied as constraints within the isolated build environment used for the package build. This resolves an issue where conflicts between cibuildwheel's internal requirements and a project's build-system.requires would cause cryptic build failures.

The Problem
Currently, on macOS, Windows, and Pyodide platforms, cibuildwheel injects its own dependency constraints (from CIBW_DEPENDENCY_VERSIONS or the defaults) into the isolated environment where a project's build-time dependencies are installed.

This leads to an issue: if a project specifies a build requirement in pyproject.toml (e.g., conan) that has a dependency conflict with cibuildwheel's constraints (e.g., on urllib3), the build fails with an unhelpful subprocess.CalledProcessError traceback.

This behaviour is also inconsistent, as it does not occur on Linux, which invokes the build without injecting these internal constraints.

The Solution
Remove the logic that sets the PIP_CONSTRAINT and UV_CONSTRAINT environment variables on the build_env before invoking the build frontend (pip wheel or build).

The effect is:

• The user's project's build-time dependencies are now resolved independently, without interference from cibuildwheel's toolchain constraints.

• The build process behaviour is now the same across all platforms (Linux, macOS, Windows, and Pyodide)

[agriyakhetarpal]

Thanks, @joerick! While this is a very rare problem to occur, as noted via #2570's reproducer, it’s good that we are aligning our process with Linux/Docker builds.

[joerick]

The tests are asserting on the version of pip in the build venv, which is reasonable to pin. So I'll try to pin that. But the current structure of the integration test checks the versions in the venv during build of the package, whereas we're more interested in the versions of the tools like virtualenv, or delocate. So I'll think about how we might change that test.

[freakboy3742]

👍 Seems reasonable to me from an iOS perspective, and I can't fault the general logic.

[ryanking13]

Looks good for Pyodide

[joerick]

I decided not to pin the version of pip inside the build venv. It was not as easy as setting VIRTUALENV_PIP (this doesn't appear to do anything, fwiw, I think that pip/build uses python -m venv). Instead it would require us to set PIP_CONSTRAINTS again, which is a bit of complexity that I'm not sure we need, and since we don't do it on Linux.