ci(plugins): gate the three loader mods (JDK 17 wrapper builds) in CI and release

Nothing ever compiled these modules — no CI job, no install path — which is
why the gradlew exec-bit bug (previous commit) shipped unnoticed.  Add
plugins/test-mods.sh: runs each module's vendored wrapper under JDK 17
(they target the Java-17 Minecraft lines; paper/limbo stay on the JDK 21
gate).  ci.yml gains a `mods` job (temurin 17 + setup-gradle, wrapper
pinned per module), release.yml gates both plugin gates before shipping.
README: status now records the server-boot verification, the Building
section pins limbo's `-PlimboVersion=<release>` (the `+` default is
unresolvable from the LOOHP repo) and documents both gates.

.github/workflows/ci.yml

@@ -118,3 +118,22 @@ jobs:
           gradle-version: '8.14'
 
       - run: bash plugins/test.sh
+
+  mods:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      # The three loader mods (Minecraft 1.20.1 / 1.20.4, Java-17 lines) compile
+      # through their vendored Gradle wrappers, which fetch their own Gradle. Until
+      # this job nothing ever built them: no install path touches them, and their
+      # gradlew scripts were committed without the exec bit, so the README's
+      # one-liners failed on a fresh clone.
+      - uses: actions/setup-java@v4
+        with:
+          distribution: temurin
+          java-version: '17'
+
+      - uses: gradle/actions/setup-gradle@v4
+
+      - run: bash plugins/test-mods.sh

.github/workflows/release.yml

@@ -40,6 +40,31 @@ jobs:
       - run: go vet ./...
       - run: go test ./...
 
+      # The same reason, for the Java layer the binary EMBEDS: the release asset is
+      # the tree's plugin sources (bootstrap_asset.go), and a tag whose plugins don't
+      # compile turns every install of that release into a failed bootstrap. JDK 21
+      # gates the install-time plugins + codec/invite tests; JDK 17 gates the loader
+      # mods (their vendored wrappers fetch their own Gradle).
+      - uses: actions/setup-java@v4
+        with:
+          distribution: temurin
+          java-version: '21'
+
+      - uses: gradle/actions/setup-gradle@v4
+        with:
+          gradle-version: '8.14'
+
+      - run: bash plugins/test.sh
+
+      - uses: actions/setup-java@v4
+        with:
+          distribution: temurin
+          java-version: '17'
+
+      - uses: gradle/actions/setup-gradle@v4
+
+      - run: bash plugins/test-mods.sh
+
       # Both architectures, because bootstrap's default release channel DOWNLOADS these
       # rather than compiling on the target host — an arm64 host with no asset silently
       # falls back to a slow source build. Neither stage is emulated: the Dockerfile pins

plugins/README.md

@@ -175,10 +175,13 @@ before the proxy Connects them.
 
 > **Status.** This slice is **code-complete and compile-verified** (paper jar
 > builds green on a Java-21 toolchain; the velocity end compiles the full shared
-> tree; the wire codec round-trips). It is **not** live-verified — there is no
+> tree; the wire codec round-trips; the fabric/forge/neoforge mods compile through
-> running Paper + Velocity + real players in this environment — so §27 scenario 10
+> their vendored wrappers and boot real dedicated servers with `/link` registered —
-> stays **FAIL (live-unverified)** in the spec matrix until it can be exercised
+> all of it gated by CI). It is **not** client-verified:
-> end-to-end on a real deployment.
+> no real game client has joined through the stack, so §27 scenario 10 stays
+> **FAIL (live-unverified)** until such a join is exercised. The client-independent
+> faces (proxy edge, subdomain MOTD, login boundary, backend registration) are
+> exercised on a live deployment — see `AUDIT-2026-09-22.md`.
 
 ## Building
 
@@ -216,7 +219,9 @@ Requires JDK 17 — **except `paper` and `limbo`, which need a Java-21 toolchain
 Gradle** (paper-api 1.21.4 is a Java-21 artifact and the Limbo API is compiled to major 65; the
 rest of the suite is Java 17). The first build of each mod downloads and remaps/decompiles Minecraft, so it
 takes a few minutes; subsequent builds are fast. Jars land in each module's
-`build/libs/`.
+`build/libs`. CI runs both gates: `bash plugins/test.sh` (JDK 21 — the install-time
+plugins plus the codec/invite tests) and `bash plugins/test-mods.sh` (JDK 17 — the
+three loader mods, via the wrappers above).
 
 ## Deploying
 

plugins/test-mods.sh

@@ -0,0 +1,30 @@
+#!/bin/bash
+# Compile gates for the three loader mods (fabric / forge / neoforge).
+#
+#     bash plugins/test-mods.sh
+#
+# Nothing installs these mods — each module's jar is its own deliverable — so
+# nothing ever compiled them either: no CI job, no install path, and the README's
+# one-liners failed on a fresh clone because the vendored gradlew scripts were
+# committed without their exec bit (fixed in the batch that added this script).
+# This is the gate that keeps "the mod still compiles" true.
+#
+# Each module pins its own Gradle via its vendored wrapper (fabric/forge: 8.8,
+# neoforge: 8.14) and targets a Java-17 Minecraft line (1.20.1 / 1.20.4), so run
+# this on JDK 17. The plugin jars bootstrap installs are different modules with a
+# different gate: plugins/test.sh (JDK 21). The first run here downloads and
+# decompiles Minecraft (minutes); the Gradle caches make later runs much faster.
+set -euo pipefail
+
+cd "$(dirname "${BASH_SOURCE[0]}")/.."
+
+major="$(java -version 2>&1 | sed -n 's/.*version "\([0-9]*\).*/\1/p' | head -1)"
+[ "$major" = "17" ] || {
+  echo "these mods target the Java-17 Minecraft lines and are built with JDK 17 (found java major ${major:-none}); set JAVA_HOME to a JDK 17" >&2
+  exit 1
+}
+
+for module in fabric forge neoforge; do
+  echo "==> plugins/${module}: ./gradlew --no-daemon build"
+  ( cd "plugins/$module" && ./gradlew --no-daemon build )
+done