pip 26.2 构建依赖拿不到 keyring，保留默认隔离的认证入口

使用虚拟环境里的 pip 构建 wheel，外层环境已经装了 keyring 后端，但日志在 Installing build dependencies 阶段突然无法从私有索引取包。若环境没有激活、pip 从 26.1.2 变为 26.2，应检查安装构建依赖的子调用是否还能导入父环境的认证组件。

这条回归出现在 Linux、Python 3.11/3.13 的默认隔离路径。原环境使用 keyrings.google-artifactregistry-auth，索引需要认证，并通过虚拟环境解释器的路径启动 pip。插件的具体发行版本没有披露，不能把一个示例后端推广为所有 keyring 或索引都存在同样故障。

pip 26.2 将安装构建依赖的步骤也置于旧构建环境的路径隔离中，遮住了父环境已经安装的 keyring。真正执行构建后端时隔离依赖是正常需要，但负责从索引取得这些依赖的安装器，也需要能使用它原来配置好的认证入口。

pip 26.2.1 恢复了默认旧隔离方式中这一步的父环境可见性；后端执行仍保留构建隔离。对于符合这条路径的项目，可以在原虚拟环境中选择该版本。下面假设项目的虚拟环境目录是 venv：

./venv/bin/python -m pip install "pip==26.2.1"
./venv/bin/python -m pip --version
./venv/bin/python -c "from importlib.metadata import version; print(version('keyring'))"
./venv/bin/python -m pip wheel --no-cache-dir --wheel-dir wheelhouse .

最后一条在需要构建的项目目录运行，保留项目原有的索引与认证配置；路径和输出目录按实际环境调整。版本查询只确认 keyring 发行包存在，不证明已经选中正确后端或取得认证。验收仍要经过原索引的构建依赖获取，再完成后端及 wheel 构建。

使用干净缓存能避免已有构建产物绕过原步骤，但会重新读取索引和取得所需包。保存最早的认证或依赖安装错误，区分远端拒绝、后端不可用和包本身不存在；只看最后的 subprocess-exited-with-error，无法确定是否命中了这条回归。

默认修补与实验选项分开验证

如果原命令启用了 --use-feature=venv-isolation，不能套用默认路径已经修复的结论。该方式使用临时环境里的 Python 执行安装器，仍有父环境认证组件可见性的边界；实验性的其他安装开关也需要按实际组合另验。

应先核对原执行方式，选择已确认的默认路径处理这条回归，不为一次升级顺便打开多个实验开关。也不必把认证组件塞进应用运行依赖，或关闭整个构建隔离：这会改变后端依赖管理，却不保证外层安装器使用了正确认证。

修复后检查三项：原认证入口仍有效、构建依赖确实重新取得、完整 wheel 能按项目原流程安装验收。认证失败若发生在另一阶段，或 keyring 在父环境本来就不可用，应按那一层的错误继续排查，不承诺升级 pip 会恢复任意私有索引。