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.

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
-> running Paper + Velocity + real players in this environment — so §27 scenario 10
-> stays **FAIL (live-unverified)** in the spec matrix until it can be exercised
-> end-to-end on a real deployment.
+> tree; the wire codec round-trips; the fabric/forge/neoforge mods compile through
+> their vendored wrappers and boot real dedicated servers with `/link` registered —
+> all of it gated by CI). It is **not** client-verified:
+> 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