Add CI workflow to test/build PrototypeMachinery and ModernBackend

[Copilot]

需要一个自动化 CI：先构建测试，再产出 PrototypeMachinery 本体与 PrototypeMachinery-ModernBackend 附属模组。

• CI workflow
  • New GitHub Actions workflow that runs tests/builds for the main mod and Modern Backend, then uploads both artifacts.

Example workflow excerpt:

- name: Test PrototypeMachinery
  run: ./gradlew test --no-daemon
- name: Build PrototypeMachinery
  run: ./gradlew build -x test --no-daemon
- name: Test Modern Backend
  working-directory: modern-backend
  run: ./gradlew test -Pjava_toolchain=21 --no-daemon
- name: Build Modern Backend
  working-directory: modern-backend
  run: ./gradlew build -x test -Pjava_toolchain=21 --no-daemon

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[Copilot]

Pull request overview

This PR adds a new GitHub Actions workflow to automate testing and building of both the main PrototypeMachinery mod and the PrototypeMachinery-ModernBackend addon. The workflow is triggered on pushes to master, pull requests, and manual dispatch, and uploads both built artifacts for distribution.

Changes:

• New CI workflow that runs tests and builds for both the main mod (Java 8) and Modern Backend addon (Java 21+)
• Automated artifact uploads for both built jar files

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The modern-backend directory does not have a src/test directory or any test source files. Running ./gradlew test will likely succeed but not actually test anything meaningful. Consider either removing the test step for Modern Backend, or adding test sources if test coverage is needed for this module.

[Copilot]

The main PrototypeMachinery build.gradle.kts specifies a Java 8 toolchain with Azul vendor preference (lines 62-65), but the workflow only sets up Java 21 via actions/setup-java. While GitHub Actions ubuntu-latest runners typically include multiple Java versions, and Gradle's toolchain will use any available Java 8 JDK if Azul is not available, this could lead to inconsistent builds. Consider either: (1) adding org.gradle.java.installations.auto-download=true to the root gradle.properties to enable automatic toolchain provisioning, or (2) setting up Java 8 explicitly in the workflow using a matrix strategy with setup-java to ensure the preferred Azul JDK 8 is available.

Suggested change

	- name: Setup Java
	uses: actions/setup-java@v4
	with:
	distribution: temurin
	java-version: 21
	cache: gradle
	- name: Setup Java 8 (Azul Zulu)
	uses: actions/setup-java@v4
	with:
	distribution: zulu
	java-version: 8
	cache: gradle
	- name: Setup Java 21 (Temurin)
	uses: actions/setup-java@v4
	with:
	distribution: temurin
	java-version: 21

[Copilot]

Consider adding a step to ensure the Gradle wrapper is executable before running gradle commands. While the gradlew file is typically checked in with executable permissions, it's a common best practice in CI to explicitly set permissions. Add chmod +x gradlew before the first gradle command, or use chmod +x gradlew modern-backend/gradlew to set permissions for both wrappers.

Suggested change

	- name: Ensure Gradle wrappers are executable
	run: chmod +x gradlew modern-backend/gradlew

[Copilot]

The Modern Backend build requires the main PrototypeMachinery jar to exist in ../build/libs before it can compile (see modern-backend/build.gradle lines 130-151 and 294-303). The build order in this workflow is correct since PrototypeMachinery is built before Modern Backend, but this dependency could be made more explicit and robust by checking that the jar exists or by failing earlier with a clear message if the PrototypeMachinery build step is skipped or fails.