build 1.4.1 在 uv 虚拟环境报 No module named pip

uv 创建的虚拟环境中已经安装 build[virtualenv]，升级到 build 1.4.1 后，python -m build 却在安装隔离构建依赖时失败：

Creating isolated environment: venv+pip...
.../python -m pip --python ... install ...
No module named pip

这条路径需要检查运行 build 的外层环境。uv 默认创建的环境可以没有 pip；build 1.4.1 却可能误判外层 pip 可用，随后用这份解释器执行根本不存在的 pip。

它与项目 setup.py 在隔离环境里自己调用 pip 不同：这里失败的是构建前端选择安装器的逻辑，通常尚未进入项目自己的构建钩子。往 build-system.requires 随意加入 pip，不能修正外层选择。

采用修正了检测逻辑的 build

build 1.4.2 已修复 _has_valid_outer_pip 在 pip 缺失时返回真值的问题。当前正式 1.6.1 仍保留缺失判断；若采用这一版本，还需核对项目运行它的 Python 与其他工具约束。

通过管理这套构建环境的正常流程更新 build，并保留项目需要的 virtualenv 扩展依赖。不能只看项目运行依赖中写了新版 build，就认定 CI 用的命令行工具已经同步更新。

在外层确实没有可用 pip、又安装了兼容 virtualenv 时，修正后的检测允许回到 virtualenv 安装路径。它不代表任何不带 pip 的环境都无需安装器；virtualenv 也不存在或不兼容时，仍需按所选构建前端的支持方式准备环境。

暂时无法更新时，显式给外层环境配 pip

新建项目专用构建环境时，可以让 uv 一并准备种子包：

uv venv --seed .venv-build

这会创建环境并安装 pip 等种子包，不是只读检查。示例使用新的 .venv-build，不要未经检查覆盖仍在使用的环境；后续安装 build 和执行构建都必须使用这一环境。实际由 tox-uv 管理时，应在该工具对应的环境配置里启用种子包，而不是在另一个终端临时激活一个无关 venv。

保留旧锁文件、工具版本与构建日志，修正后恢复默认隔离构建。日志应能完成隔离环境创建、构建依赖安装，以及 sdist、wheel 生成，再检查产物的包名、版本和必要文件。将新 sdist 放到干净构建环境再生成 wheel，可避免工作目录中的额外文件掩盖遗漏。

如果新的错误已经发生在后端或编译器中，按新的首个异常继续排查；No module named pip 消失不等于整个项目已经构建成功。也不必为了绕过这个前端回归，给所有项目加入 --no-isolation。