claude: silence GPG passphrase-decryption stacktrace in release logs

[Liam-DeVoe]

Claude-written description

Every release job run logs a ~110-line SecDispatcherException stacktrace (printed three times as a nested cause chain) from maven-gpg-plugin before signing. It is harmless — signing succeeds and the job is green — but it makes the release logs noisy and looks alarming.

Root cause: actions/setup-java templates a gpg.passphrase server entry into the runner's ~/.m2/settings.xml whenever gpg-private-key is supplied, even though this workflow sets no gpg-passphrase input. maven-gpg-plugin then runs that entry through Maven's settings decrypter, which unconditionally tries to read ~/.m2/settings-security.xml (absent on a fresh runner), and the plugin logs the resulting FileNotFoundException at WARN with the full cause chain before falling back to the plaintext value. The release key has no passphrase, so the value is never actually needed.

Fix: enable <bestPractices>true</bestPractices> on the gpg plugin's sign execution. Verified against the 3.2.7 plugin source: with bestPractices on, passphraseServerId is no longer defaulted to gpg.passphrase, so the settings.xml lookup (and its stacktrace + "W A R N I N G" block) is skipped entirely; enforceBestPractices() only throws if a passphrase or server id is explicitly configured, which they aren't. If the key ever gains a passphrase, the MAVEN_GPG_PASSPHRASE environment variable still works — it is checked first.

Rejected alternative: setting MAVEN_GPG_PASSPHRASE: "" in the workflow env. The plugin uses isNotBlank() on the env value, so an empty string falls through to the settings lookup anyway.

No RELEASE.md: the published artifact would be bit-for-bit unchanged, so this PR carries the skip release label instead (created the label, since check-release.yml and RELEASE-sample.md already reference it).