Require explicit java_version for manual java-variant builds; remove repo-var fallback

Parent Issue

Follow-up to #33865 (Java 25 migration), after #35914 (Java 25 default) and #35915 (variant auto-build retired).

Problem Statement

cicd_7-release-java-variant.yml is now manual-only, but it still falls back to the RELEASE_JAVA_VARIANT_VERSION / RELEASE_JAVA_VARIANT_SUFFIX repository variables when the java_version input is left empty. These vars still point at Java 25, which is now the default build — so an empty dispatch produces a redundant duplicate of the primary release image. Worse, if the vars were simply deleted, an empty dispatch would fall through to .sdkmanrc with no suffix and overwrite the primary release Docker tags.

This leaves two places where "the default Java" effectively lives: .sdkmanrc and the repo vars.

Proposed Solution

Make .sdkmanrc the single source of truth and require deliberate user action for any variant build:

• Make java_version a required dispatch input; remove all vars.RELEASE_JAVA_VARIANT_* fallbacks from the workflow.
• Add a fail-fast guard: read .sdkmanrc from the release branch being built and error out if the requested version is empty or equals the default (the primary release image already covers it).
• After merge: delete the RELEASE_JAVA_VARIANT_VERSION and RELEASE_JAVA_VARIANT_SUFFIX repository variables.

Outcome

A variant build (e.g. a future java-29) requires explicitly dispatching with a Java version that differs from the default — no silent fallbacks, no config drift.

Start with cicd_7-release-java-variant.yml and inspect how the manual java_version input and repository-variable fallbacks are handled. Read .sdkmanrc on the release branch to understand the default version, then verify that an empty or default-version dispatch fails fast and that only an explicitly different variant can build; remove the obsolete repository variables after the workflow change.