Add NeoForge build target for MC 1.21.1 / 26.1+, multi-version release workflow, and Windows build fix

[GaborWnuk]

What this adds

Immersive Vehicles has shipped NeoForge builds for a while (1.21.1, and 26.1.2 since May 2026),
but this repo could only produce Forge 1.16.5 and 1.12.2 jars — so there was no official pack
jar that loads on NeoForge. On NeoForge the pack has to be a real mod: InterfaceCore.getPackResource
resolves pack assets through the game classloader, so a plain assets jar isn't enough, and FML on
26.1 dropped lowcodefml, so the jar needs a compiled @Mod class again.

This PR adds that build target plus a release pipeline, in four independent pieces (one commit each):

1. Fix the 1.16.5 build on Windows

Runtime.exec("gradlew.bat build") fails on current Windows/Java setups (newer JDK 8 builds and
machines with NoDefaultCurrentDirectoryInExePath=1 no longer resolve bare .bat names against
the working directory), and the failure was silent because the Gradle output was captured but never
printed. The wrapper is now invoked as cmd /c .\gradlew.bat build, and if no jar is produced the
Gradle output is printed so the cause is visible.

2. NeoForge pack target (java PackCompiler 26, alias neo)

• Generates and compiles a NeoForgePackLoader dummy class per pack (same trick as
  ForgePackLoader, but with the net.neoforged.fml.common.Mod annotation), compiled against
  FML 11.0.15 downloaded once from the NeoForged maven and cached under build/.
• Compiled with --release 8, so the class loads on Java 21 (1.21.1) and Java 25 (26.1+) alike.
  A JDK 25+ compiler is required to run this mode (FML 11 class files are Java 25 format);
  the script checks and explains this. Default no-arg behavior is unchanged — existing JDK 8
  workflows are unaffected.
• Adds neoforge/neoforge.mods.toml (javafml [1,), mts [22.6.0,) — same floor as the
  CurseForge 1.21.1 pack file) with the version substituted from build.gradle at build time,
  and neoforge/pack.mcmeta using the 26.1 min_format/max_format scheme
  (resources 84.0 / data 101.1).
• One jar covers both NeoForge lines: MTS Official Pack-neoforge-<ver>.jar.
• CI (build.yml) builds it in a JDK 25 step after the existing JDK 8 steps.

3. Release workflow (release.yml)

Pushing a V*/v* tag builds everything and attaches per-version files to a GitHub Release,
named the same way the pack is published on CurseForge:

Minecraft	Loader	Source build
1.12.2	Forge	assets jar
1.16.5 / 1.18.2 / 1.19.2 / 1.20.1	Forge	1.16.5 jar (loaderVersion [36,) spans FML 36–46, same as the CurseForge files)
1.21.1 / 26.1.2+	NeoForge	NeoForge jar

workflow_dispatch runs the same build as a dry run (artifacts only, no release).

4. README

Pack description (based on the Modrinth page), supported-versions table, and build instructions
for all PackCompiler modes.

How it was tested

• Real dedicated-server boots with the built jar and the released core mod:
  • NeoForge 26.1.2.78 + Immersive Vehicles 26.1 build → pack discovered, content parsed
    (LegacyCompatSystem log lines reference pack models), server reaches Done.
  • NeoForge 21.1.235 + Immersive Vehicles 1.21.1 build → same result.
  • Dependency enforcement: without mts installed the loader fails cleanly with
    "Mod mtsofficialpack requires mts".
• Full default build (java PackCompiler) re-verified under JDK 8 → 1.16.5 + 1.12.2 jars as before.
• Both workflows proven green end-to-end on my fork, including a published release with all
  seven files: https://github.com/GaborWnuk/MTSOfficialPack/releases/tag/V25

Unrelated observations (not addressed here)

• src/main/resources/META-INF/mods.toml says version="24" while build.gradle is V25.
• The core mod's own mts:advancement/*.json files fail to parse on 26.1.2 (reproduces without
  any pack installed) — happy to open an issue on the core repo with logs if useful.