Fix the same release-token bug in the Android release workflow

[parawanderer]

build-release.yml has the identical wiring that broke the exporter release:

        env:
          GITHUB_TOKEN: ${{ secrets.ANDROID_BUILD_RELEASE_GITHUB_TOKEN }}

softprops/action-gh-release@v2 takes its credential as the token input, which defaults to ${{ github.token }}. Its own docs: "a non-empty explicit token overrides GITHUB_TOKEN" — the default is always non-empty, so an env var is ignored outright. The action then authenticates as the built-in token, which is read-only in this repository, and fails with 403 Resource not accessible by integration.

#54 fixed this for the macOS exporter, because that was the release being cut at the time. This workflow was never re-run, so it has been sitting on the same fault — and the next Android release would have failed at the very last step, after building and signing the APK.

Found while checking what stood between here and an Android release, rather than by running it.

Fix

• token moved into with:
• permissions: contents: write on the job, so an unset or expired PAT degrades to a working upload rather than a 403

Other workflows

update-contributors.yml also sets GITHUB_TOKEN as an environment variable, but that is the built-in token being handed to scripts/fetch_contributors.py, which reads it from the environment. Different thing, correct as written. No other instances.

Still asymmetric, deliberately not fixed here

The exporter release verifies its tag against VERSION in the source before either binary builds (scripts/exporter_version.py, gated in test-release-version). The Android release has no equivalent, so an android-app-v* tag can drift from versionName the way the exporter's used to. Worth closing separately — this PR is only the thing that would break the next release outright.

🤖 Generated with Claude Code