JUnit launcher 版本变空：检查 mavenLocal 是否抢先提供不完整元数据

自定义 JvmTestSuite 在解析运行依赖时失败，错误是：

Could not find org.junit.platform:junit-platform-launcher:.

冒号后没有版本是关键。它不等于仓库缺少某个已指定的 launcher 版本。Gradle 9.7.0 的具体场景中，mavenLocal() 排在 Maven Central 前面，本地已有 JUnit Jupiter 5.12.2 的 POM 和 JAR，却没有远端提供的 Gradle Module Metadata；测试套件需要的版本约束因此没有按预期进入解析结果。

确认 JUnit 元数据从哪里来

检查仓库声明顺序以及本地 Maven 仓库是否有这组 JUnit 模块。不要只看 JAR 存在：依赖关系、BOM 约束和 Gradle 模块信息同样会影响运行依赖。

仓库通常不是“先拿到一份 POM，再自动向下一家补全所有缺失信息”的拼接关系。某仓库已经提供这个模块的元数据后，不能假定 Gradle 会从另一个仓库替它补齐。

在具体案例中，远端完整元数据能够使 launcher 解析到 1.12.2。这个数字仅说明该组 JUnit 5.12.2 的配套结果，不是要求所有项目固定使用历史版本。

让本地仓库只承担必要的开发用途

如果项目没有依赖本机安装的制品，可移除 mavenLocal()。确实需要它时，可把远端放在前面：

repositories {
    mavenCentral()
    mavenLocal()
}

此片段应合并到原仓库配置，保留私有仓库及其内容边界。如果组织要求由内部镜像提供依赖，应把对应镜像放在合适位置，不要为解决本地问题绕开组织仓库。

另一条更明确的做法是为 mavenLocal() 设置内容过滤，仅允许本机正在开发的 group，不让它提供 JUnit 等第三方模块。过滤范围应按项目真实坐标定义，避免把未发布的内部依赖也排除。

不要随便给 launcher 填一个与现有 JUnit 不配套的版本来消除空冒号。显式 BOM 可以作为一致性策略，但仍应确认它应用到了这个自定义套件的配置；只在主源码的 implementation 上声明，不代表所有测试配置都得到约束。

调整前保存仓库顺序和解析结果。重新解析原失败配置，再运行该套件，核对 launcher 有非空且配套的版本、测试实际执行。无需删除整个 .m2/repository；本地安装的其他项目制品不属于这次修复范围。