General: Migrate Pages deploy to GitHub Actions and refresh Node-20 actions

[d4rken]

What changed

No user-facing behavior change. CI/CD maintenance to clear Node 20 deprecation warnings and a dead cache step before GitHub forces Node 24 on 2026-06-02 and removes Node 20 on 2026-09-16 (changelog).

Focused changes:

1. Custom Pages workflow (.github/workflows/pages.yml) replacing GitHub's auto pages-build-deployment (which still pins actions/checkout@v4 + actions/upload-artifact@v4 on Node 20). Uses configure-pages@v6, jekyll-build-pages@v1.0.13, upload-pages-artifact@v5, deploy-pages@v5 — all on Node 24 or Docker. Triggered on push: main + workflow_dispatch, with a JEKYLL_GITHUB_TOKEN env on the build step (authenticates jekyll-github-metadata against the GitHub API), if: github.ref == 'refs/heads/main' guard on the deploy job (prevents accidental deploys from feature branches via workflow_dispatch), per-job permissions split (top-level contents: read; deploy job adds pages: write + id-token: write), and a sanity check (test -f _site/index.html && test -f _site/CNAME) before upload.
2. Chain-trigger from release-tag.yml: a new step at the end of the release-github job runs gh workflow run pages.yml --ref main after the GitHub Release is created. Required because CHANGELOG.md is a Liquid template that loops site.github.releases (the GitHub Releases API at build time, not file content), so the Pages site needs to rebuild after the release exists in the API. The natural push: main triggered build runs before release-tag.yml finishes creating the release and would publish a stale /changelog. The chain step fires through workflow_dispatch, which is one of the two events that bypass the GITHUB_TOKEN recursion restriction. Adds actions: write permission on release-github.
3. Gemfile relocation: moved Gemfile/Gemfile.lock into fastlane/. The Jekyll Pages builder reads SOURCE/Gemfile and our root Gemfile only declared gem "fastlane", which conflicted with github-pages. The release-gplay job now sets BUNDLE_GEMFILE and ruby/setup-ruby's working-directory to fastlane; bundle exec fastlane … keeps running from the repo root so fastlane discovery is unchanged. Plus a Verify fastlane Bundler wiring step that runs unconditionally so workflow_dispatch dry_run=true exercises the relocation end-to-end before the next real beta tag.
4. softprops/action-gh-release v2.5.0 → v3.0.0 in release-tag.yml. v3 is the only line that runs on Node 24; inputs we use (prerelease, tag_name, name, generate_release_notes, files) are unchanged.
5. Drop the dead Android global build-cache step in common-setup. Android Gradle Plugin 7+ no longer creates that path, so actions/cache emitted Path Validation Error: Path(s) specified in the action for caching do(es) not exist on every job without saving anything useful. We're on AGP 9.0.1.
6. _config.yml cleanup: dropped the now-dead - Gemfile / - Gemfile.lock excludes since the files no longer live at the root.
7. .gitignore: added _site/, .jekyll-cache/, vendor/bundle/ for local Jekyll iteration.

Mirrors sdmaid-se PR #2402 and capod PR #556 with one notable scope difference and one trigger-architecture difference vs capod:

• Pages trigger is push: main + chain, not release: published + chain. Capod uses release: published because they want only release-driven rebuilds; we follow sdmaid-se in also rebuilding on regular main pushes (e.g. README/_config.yml/PRIVACY_POLICY.md edits). The race against release-tag.yml exists either way; the chain trigger fixes it for both architectures.
• dorny/test-reporter v3 bump from sdmaid-se PR #2402 is dropped here — BlueMusic doesn't have a test-reports.yml workflow.

Review checklist

• Pre-merge: gh api -X PUT repos/d4rken-org/bluemusic/pages -f build_type=workflow already run; gh api repos/d4rken-org/bluemusic/pages --jq '{build_type,cname,https_enforced}' confirmed build_type=workflow, cname=bluemusic.darken.eu, https_enforced=true.
• After merge, the new "Deploy GitHub Pages" workflow runs on the merge commit and the legacy pages-build-deployment run no longer appears.
• Annotations panel on the Pages run is empty (no Node 20 / no github-pages gem warnings); annotations on "Code tests & eval" no longer include the cache Path Validation Error from the dropped step.
• bluemusic.darken.eu/changelog still renders the GitHub Releases changelog after the merge build.
• workflow_dispatch on Tagged releases with dry_run=true: the new Verify fastlane Bundler wiring step succeeds (proves the Gemfile relocation is wired correctly before any real beta tag).
• Next real v* tag is the first end-to-end check of action-gh-release v3.0.0 and the chain trigger — verify /changelog shows the new release shortly after release-tag.yml finishes.

[d4rken]

Two things from comparing with the parallel sister-repo PRs (the capod equivalent is at d4rken-org/capod#556, with the most detail on the race in d4rken-org/permission-pilot#356):

1. No release → Pages chain — pre-existing race not fixed

Current trigger is push: [main] + workflow_dispatch. The Pages workflow fires when the release commit lands on main, but the GitHub Release itself only appears minutes later (after release-tag.yml finishes its APK build). site.github.releases therefore captures a snapshot without the new release, and the changelog page silently misses the entry until the next unrelated push to main.

permission-pilot#356 documented the timing on that repo ("v2.1.0-rc0 missed by 22 min, v2.0.3-rc0 missed by 41 min"). Same race exists here.

Fix: add a step in release-tag.yml's release-github job, after the release-create step:

      - name: Trigger GitHub Pages deployment
        if: "!(github.event_name == 'workflow_dispatch' && inputs.dry_run)"
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: gh workflow run pages.yml --ref main

Plus actions: write on that job's permissions: block (the gh workflow run API call requires it; otherwise it depends on the repo's default workflow-token permissions and may 403 silently).

The existing concurrency: group: pages, cancel-in-progress: false will serialise the chained run behind the push: [main] run, so the second run picks up the just-published release.

2. JEKYLL_GITHUB_TOKEN missing on the Jekyll build step

Without it, jekyll-github-metadata falls back to anonymous GitHub API access when populating site.github.releases — anonymous calls hit a 60/hr rate limit shared with the runner IP. Risk of incomplete release lists or build failures during busy CI periods.

Add to the Build with Jekyll step:

      - name: Build with Jekyll
        uses: actions/jekyll-build-pages@...
        with:
          source: ./
          destination: ./_site
        env:
          JEKYLL_GITHUB_TOKEN: ${{ github.token }}