Fail closed when release JAR selection is ambiguous or development-only

[Exohayvan]

Summary

package_release_target.py excludes sources and javadoc JARs but allows development classifiers, then chooses the newest matching file by modification time.

Evidence

• common/scripts/package_release_target.py:170-182 permits -dev.jar and -all-dev.jar files.
• When multiple candidates match the version, it logs a warning and selects max(st_mtime).
• A read-only audit probe with a production JAR and newer development JAR selected the development JAR.
• curseforge_testing.py already uses stricter rules that exclude dev/all-dev artifacts, so release and testing selectors disagree.

Impact

GitHub, Modrinth, and CurseForge can receive a remapped or development artifact instead of the production mod JAR.

Reproduction / verification

• Populate build/libs with production, dev, all-dev, sources, and javadoc artifacts in varied timestamp orders.
• Require deterministic selection of exactly one production artifact or an explicit failure.

Proposed direction

Share one strict artifact-selection helper between test and release tooling, exclude all classifier artifacts, and fail on ambiguity. Prefer a build-generated artifact manifest with path and digest.

Acceptance criteria

• Development/classifier JARs cannot be selected for publication.
• Ambiguous production candidates stop the release.
• Tests cover all supported loader artifact layouts and timestamp orders.

Audit provenance

Candidate #9 from the read-only repository audit performed on 2026-07-20. This is separate from existing issues #3, #4, #25, and #27 unless explicitly linked later.