ci: add master-only release JAR build workflow

[halibobo1205]

What does this PR do?

Adds a manually triggered (workflow_dispatch) GitHub Actions workflow that builds java-tron release JARs from master.

The workflow:

• rejects runs dispatched from any ref other than refs/heads/master;
• builds x64 JARs inside the eclipse-temurin:8-jdk container (JDK 8), matching the existing PR CI build environment;
• builds aarch64 JARs on ubuntu-24.04-arm with Temurin 17;
• records the source commit, ref, workflow run URL, architecture, and java -version in per-architecture metadata files;
• smoke-tests FullNode, Toolkit, and ArchiveManifest on both architectures;
• assembles the nine release JAR filenames used by existing releases;
• generates SHA-256 checksums and uploads a combined release artifact.

The final artifact contains:

FullNode.jar
FullNode-x64.jar
FullNode-aarch64.jar
Toolkit.jar
Toolkit-x64.jar
Toolkit-aarch64.jar
ArchiveManifest.jar
ArchiveManifest-x64.jar
ArchiveManifest-aarch64.jar
SHA256SUMS
build-metadata-x64.txt
build-metadata-aarch64.txt

The unsuffixed JARs are copies of their x64 counterparts, preserving the existing release naming convention.

Why are these changes required?

Release JARs are currently built on developers' local machines, where build environments and procedures may differ. Moving the build into CI provides consistent architecture-specific environments and makes each artifact traceable to its source commit and workflow run. Release publishers can download the CI artifact and upload the JARs without rebuilding them locally.

This PR has been tested by:

• Manual Testing

Each architecture job runs:

java -jar FullNode.jar --version
java -jar Toolkit.jar help
java -jar ArchiveManifest.jar -h

The workflow additionally verifies that:

• FullNode --version reports the expected commit SHA, binding the artifact to the source commit;
• x64 and aarch64 JARs are not identical, guarding against artifact mix-ups;
• all nine expected JARs are present;
• SHA256SUMS contains checksums for all nine JARs.

The implementation was locally validated with:

• YAML syntax validation;
• embedded shell-script syntax validation;
• Gradle release-task dry run;
• an ARM64 release JAR build with Temurin JDK 17;
• FullNode, Toolkit, and ArchiveManifest smoke tests;
• artifact assembly and checksum generation using local fixtures.

Follow up

The following are outside the scope of this PR:

• GPG signing;
• automatic GitHub Release publishing;
• dispatching builds from tags for historical release reconstruction;
• bit-identical reproducible builds.

Extra details

• The workflow only builds and smoke-tests release JARs. Unit and integration tests remain covered by the existing PR CI workflows.
• GitHub's Actions UI lists a workflow_dispatch workflow only after the file exists on the default branch. Release managers then select master, so the workflow must also have propagated to master before it can be used.
• Intermediate x64 and aarch64 artifacts are retained for 7 days.
• The final combined artifact is retained for 30 days.
• Artifact overwrite is enabled so complete workflow reruns do not fail because artifacts with the same names already exist.
• No breaking changes are introduced, and the existing release JAR filenames remain unchanged.

[bladehan1]

Consider integrating automatic GPG signing?

[halibobo1205]

Consider integrating automatic GPG signing?

Automatic GPG signing is not included in this PR. @bladehan1

The current release signing key is stored on a physical YubiKey, which GitHub-hosted runners cannot access. The signing process may also require PIN entry or physical touch, depending on the YubiKey policy.

If we decide that this model is appropriate for java-tron's release security requirements, one option would be a dedicated, hardened self-hosted runner physically connected to the YubiKey, similar to the release-signing setup used by libp2p. Another option would be migration to a remotely accessible HSM or signing service.

Either option would require a separate decision and security review covering runner isolation, access control, approval, auditing, and PIN/touch handling.

For now, this workflow produces checksummed release artifacts. A release maintainer downloads those exact artifacts, signs them with the YubiKey, and uploads the JAR and signature files without rebuilding.