[niStee]

I've noticed several workflows are running with default permissions and relying on a custom WORKFLOW_TOKEN. This PR refactors some to follow the principle of least privilege.

Changes:

Permissions Hardening: Added permissions: contents: read to all workflow headers.

Token Standardization: Migrated build-prs.yml and flatpak-build.yml from secrets.WORKFLOW_TOKEN to the built-in secrets.GITHUB_TOKEN.

Technical Considerations:

1. Security: Explicitly setting contents: read mitigates potential write-access exploits from compromised dependencies in the build chain.
2. Token Scope: Is there a specific architectural reason for using WORKFLOW_TOKEN in these files? If the built-in GITHUB_TOKEN provides the necessary scope for PR builds and artifact generation, it seems more logical to use the automatically rotated, short-lived secret.

A question on the build logic: I have applied contents: read based on the assumption that these workflows are used for validation and artifact storage. If pnpm dist or the Flatpak builder requires pushing tags or updating releases via the API, these will fail with a 403.

Does our current CI flow require write access for these automated checks, or is the restrictive "read-only" state the intended baseline?

---

Infrastructure / CI Changes

• Verified workflow syntax.
• Tested actual execution (to be confirmed by CI run).

Note: This PR does not modify Backend or Frontend logic, so standard app testing (Login/Install/Play) was not performed. The primary risk is CI permission scoping.

[CommandMC]

If pnpm dist or the Flatpak builder requires pushing tags or updating releases via the API, these will fail with a 403

These operations should run fine with the more limited permissions
In general though, you may want to look into what those commands/workflows do, instead of moving that burden to us (understand these workflows were setup years ago, I'd have to re-familiarize myself with them as well)

[niStee]

If pnpm dist or the Flatpak builder requires pushing tags or updating releases via the API, these will fail with a 403

These operations should run fine with the more limited permissions In general though, you may want to look into what those commands/workflows do, instead of moving that burden to us (understand these workflows were setup years ago, I'd have to re-familiarize myself with them as well)

Thanks for the review and for pointing out that I should dig more into what the workflows actually do.

From looking over the workflows touched in this PR and their scripts, my understanding is:

• Build workflows (build-prs.yml, build-main.yml / build-base.yml, codecheck.yml, lint.yml, test.yml):
  These appear to run the usual builds and checks (for example pnpm dist:win and pnpm dist:linux appimage --publish=never) and upload artifacts, but I don’t see anything that creates tags or modifies repository contents via the GitHub API, and electron-builder is not invoked with -p always in these paths. That’s why permissions: contents: read seemed like a reasonable least‑privilege default here.
• Flatpak workflow (flatpak-build.yml):
  This one builds an AppImage with --publish=never and then prepares Flatpak metadata from the local artifacts, so as far as I can tell it doesn’t publish anything back to GitHub and should also work with GITHUB_TOKEN / GH_TOKEN scoped to contents: read.
• AUR workflow (release_aur.yml):
  The job fetches the latest release and artifact via the public GitHub API/URLs, generates a PKGBUILD, and then uses KSXGitHub/github-actions-deploy-aur@v4.1.1 with AUR credentials and an SSH key to push to the AUR repository directly, rather than pushing to this GitHub repo or modifying releases here. Based on that, contents: read looks sufficient for this workflow as well.

That said, I may still be missing some historical or implicit behavior, so if you know of any of these workflows relying on GitHub‑side write operations that I overlooked, I’m happy to adjust the permissions for those specific cases.