fix(ci): drop invalid platform version and allow re-publishing a release

[TheMeinerLP]

The 2.9.0 release is currently broken. This fixes the cause and adds the missing way to recover.

What happened

> Task :publishAntiRedstoneClock-RemasteredPublicationToHangar FAILED
> Error uploading version, returned 400: Invalid version: 26.0

26.0 is not a Minecraft version that ever shipped, and both platforms reject it. Checked against the live lists rather than guessed:

Source	26.x versions accepted
hangar.papermc.io/api/v1/platforms/PAPER/versions	26.1, 26.1.1, 26.1.2, 26.2
api.modrinth.com/v2/tag/game_version	same — no 26.0

Every other entry in supportedMinecraftVersions is valid on both. 26.0 is the only bad one.

The damage is wider than Hangar

The publish step ran ./gradlew check shadowJar publishAllPublicationsToHangar modrinth cyclonedxBom as a single command, with Hangar first. When Hangar rejected the version, everything after it never ran:

Target	State
Git tag v2.9.0	created
GitHub release v2.9.0	created, 0 assets — the JAR was never attached
Hangar	not published
Modrinth	not published
Dependency-Track SBOM	not uploaded

And there was no way back: the publish job only runs when release-please creates a release, so once the tag existed, a failed publish was unrecoverable without cutting a throwaway version.

Changes

1. 26.0 removed from supportedMinecraftVersions. Also removes the run-26.0 / run-folia-26.0 tasks, which could never have worked either — Paper has no such build.

2. The JAR is uploaded to the GitHub release before the platform uploads. Hangar and Modrinth reject versions for reasons outside this repository's control. When that happens the artifact should still land on the release instead of dying with the run.

3. The workflow accepts workflow_dispatch, so an already-tagged release can be published again:

• tag (required) — the release tag to publish, e.g. v2.9.0
• ref (optional) — what to build from, defaults to the tag. Point it at main when the tagged commit is exactly what broke publishing, which is the case here.

A guard compares the tag against version in build.gradle.kts and refuses to publish if they disagree, so ref cannot be used to accidentally ship 2.9.1 code under the v2.9.0 tag. Verified both directions:

v2.9.0 -> ok (version 2.9.0)
v2.9.1 -> abort (tag=2.9.1, build=2.9.0)

release-please is now gated on github.event_name == 'push' so a manual dispatch does not touch the release PR, and publish uses always() so it is not skipped along with it.

Recovering 2.9.0 after this merges

main still declares version = "2.9.0", so building from main produces exactly the 2.9.0 artifact — now with a platform list Hangar accepts:

gh workflow run release-please.yml -f tag=v2.9.0 -f ref=main

That attaches the JAR to the existing v2.9.0 release, publishes to Hangar and Modrinth, and uploads the SBOM. No new version number, no moved tag.

This has to happen before the next release PR merges — once release-please bumps main to 2.9.1, the version guard will correctly refuse the v2.9.0 dispatch.

Verification

./gradlew build passes. The generated run tasks are now run-26.1, run-26.1.1, run-26.1.2, run-26.2 — no more run-26.0.

[github-actions]

Unit Test Results

  8 files    8 suites   1s ⏱️
 73 tests  73 ✅ 0 💤 0 ❌
133 runs  133 ✅ 0 💤 0 ❌

Results for commit 4df07e1.