[jkschneider]

JUnit5to6Migration upgrades Jupiter and the JUnit BOM but leaves explicitly declared JUnit Platform and Vintage dependencies on their old major versions. Its launcher addition skips an existing launcher, so a Gradle build migrated through Spring Boot 3.x → 4.2 can end up with Jupiter/engine 6.1.3 and launcher 1.14.4. Test discovery then fails with NoSuchMethodError in ExecutionRequest.create(...).

Upgrade existing org.junit.platform:* and org.junit.vintage:* declarations to 6.x alongside Jupiter. Keep the existing launcher-addition step for builds without one, and remove unsupported Platform artifacts before the group upgrade as before. This belongs in the shared JUnit migration, so non-Spring users receive the fix too. It reuses declarative dependency upgrades and adds no visitor or version pin.

Found while verifying https://github.com/moderneinc/customer-requests/issues/3176 and moderneinc/rewrite-spring#520 against pbb6w7/gs-spring-boot at base commit 7d77ad3. The original Gradle sample compiled and tested successfully; the migrated sample compiled but failed discovery. Temporarily changing only the launcher from 1.14.4 to 6.1.3 restored its passing compile/check. That diagnostic application edit was reverted; it is not a substitute for the recipe regression tests.

Validation:

• Both new Maven and Gradle regression tests failed before the YAML change and pass afterward. They include an existing launcher and Vintage engine and exercise the shipped composite.
• Full repository test compilation passes. The scoped Gradle check for the JUnit 6 family and JUnit 6 best-practices composite passes: 100 tests, zero failures; recipe catalog validators also pass.
• Ran the official recipeCsvGenerate task and kept only this migration and its parent composite's generated rows. Ran licenseFormat separately; it passes. git diff --check passes.
• The complete testing-frameworks suite was not run locally. End-to-end Spring migration verification with the updated recipe bundle is continuing under request 3176.