chore: bump actions in ci

[bitsandfoxes]

This addresses the 79 warnings that

Node.js 20 actions are deprecated.

which will hit us in June.

#skip-changelog

[bitsandfoxes]

We previously relied on this fork https://github.com/vaind/download-artifact (that is in dire need of getting synced), or, like here, we wrap action/download-artifact in 10 lines of bash and call it a day.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 977760a. Configure here.}

[sentry]

Bug: Several jobs and reusable workflows using the wait-for-artifact action are missing the required actions: read permission, which will cause API calls to fail.
_{Severity: HIGH}

Suggested Fix

Add the actions: read permission to the permissions block for all jobs that call the wait-for-artifact action. This includes the test-build-webgl and package-validation jobs in ci.yml, and the jobs in ci.yml that call the reusable test/build workflows.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: .github/actions/wait-for-artifact/action.yml#L14-L28

Potential issue: The custom `wait-for-artifact` action calls a GitHub API endpoint that
requires `actions: read` permission. While this permission was added to the `build.yml`
file and the `build-unity-sdk` job in `ci.yml`, it was not added to other jobs and
reusable workflows that also use this new action. Specifically, the `test-build-webgl`
and `package-validation` jobs in `ci.yml`, as well as the `test-build-android.yml`,
`test-build-linux.yml`, `test-build-windows.yml`, and `test-build-ios.yml` reusable
workflows, are all missing this permission. When these workflows run, the `gh api` call
will fail with a permission denied error, causing the step to fail.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[sentry]

Bug: The PowerShell script in wait-for-artifact will crash if the gh api call fails, as it tries to cast an empty string to an integer without error handling.
_{Severity: HIGH}

Suggested Fix

Wrap the gh api call and subsequent type cast in a try/catch block. In the catch block, handle the error gracefully, for instance by logging a warning and allowing the loop to continue to the next iteration. This will ensure that transient API failures do not crash the entire action and that the polling mechanism can retry as intended.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: .github/actions/wait-for-artifact/action.yml#L22-L23

Potential issue: In the `wait-for-artifact` action, the PowerShell script polls for an
artifact's existence. It executes a `gh api` command and attempts to cast the result to
an integer using `[int]$count`. If the `gh api` command fails for any reason (e.g., a
permission error, a transient network issue, or rate limiting), the output variable
`$count` will be an empty string. The cast `[int]""` then throws a terminating
`InvalidCastException`, which is unhandled and immediately crashes the entire step. This
bypasses the intended 60-minute retry loop, making the action fail instantly on any API
error rather than retrying.

_{Did we get this right? 👍 / 👎 to inform future reviews.}