Keep version-less dependency declarations untouched in refreshVersionsMigrate

[takaharu-nakase]

Fixes #740

Problem

refreshVersionsMigrate appends the version placeholder to version-less dependency declarations:

-    implementation("com.fasterxml.jackson.module:jackson-module-kotlin")
+    implementation("com.fasterxml.jackson.module:jackson-module-kotlin:_")

A version-less declaration means the version is supplied by a platform/BoM (Spring Boot dependency management, aws.sdk.kotlin:bom, …) or by dependency constraints. Migrating it to :_ always breaks the build, because the migration only adds versions.properties entries for dependencies with hardcoded versions, so the new placeholder can never resolve:

> Could not find com.fasterxml.jackson.module:jackson-module-kotlin:_.

Because the rewrite is textual, it also corrupts string literals that merely look like coordinates, e.g. resolutionStrategy.eachDependency matchers ("co.elastic.clients:elasticsearch-java" -> useVersion(…) becomes "co.elastic.clients:elasticsearch-java:_" -> …, which never matches again).

The cause is the empty alternative in mavenCoordinateRegex ((?:|:_|:$versionChars{3,})), which makes the fallback replacement match coordinates without a version.

Fix

Introduce mavenCoordinateWithVersionRegex (same regex, without the empty alternative) and use it for the :_ fallback replacement only. Version-less coordinates are now left untouched by the fallback.

The replacement of version-less coordinates with built-in dependency notations, when a mapping exists, is intentionally kept as-is (behavior covered by the existing "Replace with dependency names, if present" test via org.apache.logging.log4j:log4j-jul).

Testing

• New test case "Keep version-less maven coordinates untouched in build files" in MigrationTest
• ./gradlew :refreshVersions:test --tests "de.fayard.refreshVersions.MigrationTest" passes

🤖 Generated with Claude Code

[takaharu-nakase]

CI failure analysis: pre-existing on main, not caused by this change

The check-all job fails at the "Check for memory leaks" step, which stress-runs the sample-groovy build 10 times in a daemon capped at -Xmx150M. The OOM happens on run number 1, during Kotlin DSL script compilation of sample-groovy/buildSrc/build.gradle.kts — before any repeated-build accumulation could show up:

Run number 1
e: Java heap space (build.gradle.kts): java.lang.OutOfMemoryError: Java heap space

To rule this PR out, I dispatched the same workflow on unmodified main in my fork, and it fails identically at the same step, also on run number 1:

• This PR: https://github.com/Splitties/refreshVersions/actions/runs/30515345150
• Unmodified main (control run): https://github.com/takaharu-nakase/refreshVersions/actions/runs/30515593606

The last green runs of this workflow were on 2026-07-01 (PR #739's re-run) and 2025-08-16 (main), so it looks like the current GitHub-hosted runner environment now needs more than 150 MiB for Gradle 9 script compilation, which makes the step fail for any PR regardless of its content.

I'm verifying a heap bump for the stress test on my fork and will send a companion PR if it goes green.

[takaharu-nakase]

I've cherry-picked the CI fix from #742 onto this branch so CI can actually run for this PR — happy to drop that commit once #742 lands. Verification of the workflow fix on unmodified main: https://github.com/takaharu-nakase/refreshVersions/actions/runs/30515882804