Fix CHANGES.txt generation in snapshot and release builds

[MostCromulent]

@tool4ever as discussed:

---

Problem

Before PR #8410, CHANGES.txt was a committed file in the source tree — CI shallow clones always had it regardless of whether the changelog plugin could regenerate it. PR #8410 deleted that file, moved the output to target/, and added a Groovy script to dynamically find the latest forge-* tag. The motivation was to stop CHANGES.txt showing up as a modified file in git status after every local build.

This worked in development because local clones have full git history and all tags available. It broke in snapshot and release builds because CI workflows use shallow clones (fetch-depth: 1) — they download only the latest commit for speed, not the full history. The Groovy script finds no forge-* tags in the shallow clone and falls back to fromRef=refs/tags/HEAD, an invalid git ref. The changelog plugin either errors or produces a single-entry changelog containing only the HEAD commit, instead of the full list of changes since the last release.

Additionally:

1. The Mustache template produces noisy output. Every commit gets wrapped in ### No issue headers because Forge doesn't configure issue tracker integration. The Java parser (TextUtil.getFormattedChangelog) already strips these, but they clutter the raw file shipped in Mac DMGs.

2. Windows compatibility. git tag output can contain \r on Windows, causing tag name matching to fail silently.

3. Deprecated actions. Three workflows still use actions/checkout@v3 (Node 16 EOL).

Changes

CI: fetch just enough history for changelog generation (4 workflow files)

Instead of switching to fetch-depth: 0 (which downloads the full 1 GB+ repo history), the workflows use the GitHub API to find the latest forge-* tag's commit date, then deepen the shallow clone to just that date with git fetch --shallow-since. This adds ~4 MB and ~2 seconds to each build.

• snapshot-both-pc-android.yml — add changelog fetch step
• snapshots-pc.yml — upgrade checkout v3→v4, add changelog fetch step
• maven-publish.yml — upgrade checkout v3→v4, add changelog fetch step
• snapshots-android.yml — upgrade checkout v3→v4, add changelog fetch step (android assets include CHANGES.txt from the desktop build)

Groovy script hardening (forge-gui-desktop/pom.xml)

• Add .trim() to tag names to strip \r on Windows
• Log a warning when no tags are found instead of silently falling back
• Drop refs/tags/ prefix from fromRef — bare tag names resolve correctly, and the HEAD fallback no longer produces the invalid ref refs/tags/HEAD

Simplify Mustache template (forge-gui-desktop/pom.xml)

Remove ## {{name}} tag headers, ### No issue headers, and hasIssue/hasLink grouping. These were stripped by TextUtil.getFormattedChangelog anyway and added noise to the raw file.

Testing done

Simulated CI by creating a shallow clone (git clone --depth 1), then ran the GitHub API + git fetch --shallow-since approach. The clone grew from 228 MB to 232 MB (+4 MB) in 1.6 seconds, the forge-2.0.10 tag was fetched automatically, and mvn -pl forge-gui-desktop -am package -DskipTests generated an 838-line CHANGES.txt with correct content — no ##/### headers, proper commit entries with title, body, and timestamps. Also verified the Java parser (TextUtil.getFormattedChangelog) correctly extracts 20 non-merge entries from the output.

Not tested in a live GitHub Actions run — the --shallow-since fetch was verified with the file:// protocol locally. If it behaves differently over HTTPS in CI, the Groovy script falls back gracefully (empty CHANGES.txt, no build failure).

---

🤖 Generated with Claude Code

[MostCromulent]

Note that TextUtil.getFormattedChangelog still limits the user-facing changelog output to the last 20 commits even with this fix. Query whether you want to keep that limit / increase it / look at applying some differential approach between snapshot and main release builds.

[tool4ever]

that sounds fine for now