Mod releases fail on immutable releases: attach jars to a draft, then publish #65

Immutable releases are on for datapacks, bimo-mod, tallyhopper and bimo-model. A published release can no longer take assets, so any path that attaches a file after release-please publishes gets HTTP 422: Cannot upload assets to an immutable release.

Seen in datapacks: cauldron-copper-v1.0.1 went out with no zip and the Release workflow has been red on every push to main since (run 38009514354). The fix there is studiobimo/datapacks#13: draft release, upload the zip by release id, then publish.

Not yet hit, same cause: the mod release path.

• publish-mod.yml runs ./gradlew publishMods with RELEASE_TAG set, which runs attachToGithubRelease: gh release upload "$RELEASE_TAG" <jar> --clobber. Run after release-please has published, that is a 422.
• attachToGithubRelease lives in multiloader-loader.gradle, now managed by the java-gradle profile in studiobimo/project-template, so the Gradle side needs a template release.
• Neither bimo-mod nor tallyhopper has had a release yet (tallyhopper's release.yml is still dry-run: true), so this should be done before the first one.

Change

1. release-please-config.json in both mods: "draft": true and "force-tag-creation": true, so the release is a draft and the tag exists for the checkout in publish-mod.yml (ref: tag-name).
2. attachToGithubRelease: find the release by listing, not by tag (a draft has no page under its tag; gh release upload TAG looks it up by tag), and upload by id.
3. publish-mod.yml: after publishMods succeeds and the jars are attested, publish the draft (PATCH releases/{id} with draft=false). A failed Modrinth or CurseForge upload then leaves a draft that can be re-run instead of a public release with no jars.
4. Decide what dry-run does to the draft (leave it a draft).

Order: this repo (publish-mod.yml), then project-template (release), then the two mods. Check on a real release; the datapacks change is the first real test of the draft-then-publish pattern.