Potential fix for code scanning alert no. 9: Workflow does not contain permissions

[scottolsonjr]

Potential fix for https://github.com/rarelysimple/RarelySimple.AvatarScriptLink/security/code-scanning/9

In general, the fix is to explicitly declare a permissions block either at the workflow root (applies to all jobs) or under the specific job(s), granting only the minimal permissions required for the job to run. For a typical build/test/package workflow that does not push commits, create releases, or modify issues/PRs, a safe default is contents: read, which corresponds to a read-only GITHUB_TOKEN.

For this particular workflow file .github/workflows/dotnet-check-build.yml, the job simply reuses another workflow (./.github/workflows/dotnet-build.yml) to build, test, and package .NET code. There is no indication it needs to write to the repository or to issues/PRs. The best minimal, non-breaking fix is to add a root-level permissions block directly under the workflow name/run-name section, before the on: section, setting contents: read. This will apply to all jobs in this workflow (currently just build) unless overridden, and will not change existing functional behavior other than restricting any unnecessary write permissions of the GITHUB_TOKEN.

No new methods, imports, or external libraries are needed, because this is purely a YAML configuration change within the workflow file.

Suggested fixes powered by Copilot Autofix. Review carefully before merging.

[Copilot]

Pull request overview

This PR adds a root-level permissions block to the dotnet-check-build.yml GitHub Actions workflow, restricting the GITHUB_TOKEN to read-only access (contents: read). This addresses code scanning alert #9 about workflows missing explicit permissions declarations, following the principle of least privilege.

Changes:

• Added permissions: contents: read at the workflow root level in dotnet-check-build.yml to explicitly restrict the token to read-only access.