Fix the exporter release upload: token as input, not env var

[parawanderer]

The v1.0.5 release published with no assets attached. Both binaries built fine — only the last step failed:

Unexpected error fetching GitHub release for tag refs/tags/macos-exporter-v1.0.5:
HttpError: Resource not accessible by integration

Cause

softprops/action-gh-release@v2 takes its credential as the token input, which defaults to ${{ github.token }}. From the action's own action.yml:

Defaults to github.token when omitted. A non-empty explicit token overrides GITHUB_TOKEN.

Since the default is always non-empty, the GITHUB_TOKEN: env var this workflow set was ignored outright — the PAT in MACOS_EXPORTER_APP_GITHUB_TOKEN was never used. The action authenticated as the built-in token, and this repository's default workflow permission is read-only:

{"default_workflow_permissions": "read", "can_approve_pull_request_reviews": false}

so it could not update the release. The action's documentation names this exact symptom.

Setting the token via env: is the v1 idiom, which is presumably where it came from.

Fix

• pass the PAT as the token input on both build jobs
• grant permissions: contents: write to those jobs as well, so an unset or expired PAT degrades to a working upload rather than a 403 — the action treats an empty token as unset and falls back to the built-in one

Not related to the version wiring

Every step touching the APP_VERSION output added in #49 succeeded: test-release-version passed the tag/source check, and both zips were named and uploaded correctly. The failure was purely authentication on the final upload.

Unblocking v1.0.5 in the meantime

The built zips are attached to the failed run as workflow artifacts, so they can be downloaded and added to the release by hand without waiting for this. Re-running the failed jobs will not help on its own — a re-run replays the workflow file from that run, so it needs this merged and the release event re-fired.

🤖 Generated with Claude Code