bump-dependencieslisted

# Bump dependencies Every third-party version lives once, as a `<name.version>` property in `vibetags-parent/pom.xml`; the managed poms inherit it and `BuildVersionParityTest` fails the build if a literal creeps back in or a Gradle coordinate drifts. What that test cannot see is whether the pinned version is *current*, which is what this skill is for. ## Step 1 - Branch, then report ```bash git fetch origin && git checkout -b chore/bump-dependencies-$(date +%F) origin/main tools/bump-dependencies.sh # read-only; add --include-prereleases to see betas ``` The script prints one line per property with its Maven Central latest, then the toolchains pinned outside the parent (Gradle wrapper, Kotlin, Groovy, Scala 2.13). It exits 2 if the parent gains a `*.version` property the script has no Maven Central path for: add the path to its `PINS` table in the same change, so the report can never silently go stale. ## Step 2 - Decide - Apply stable releases only. Never an alpha, beta, milestone (`M1`), RC or `-ea`, even when Maven Central marks it `<latest>`; the report already hides them by default. - Read the release notes of anything with a major bump before applying it. Plugins that change how the build runs (compiler, surefire, enforcer, spotbugs, pmd, error-prone, nullaway) can turn a green build red for reasons unrelated to the code; that is not a reason to skip them, it is a reason to run the full gates below. - Kotlin: `examples/kotlin` uses kapt; a Kotli