Retry current-build dependency artifact download up to 3 times (#2314)

## Why

Builds across AL-Go consumers (e.g. BCApps) have started failing
intermittently in the `Download Project Dependencies` step with
transient network errors such as:

```
##[error]Unable to download artifact(s): Failed to GetSignedArtifactURL: Unable to make request: ETIMEDOUT
```

This happens inside `actions/download-artifact`, which calls GitHub's
Actions Results service to mint a signed blob URL before each download.
A single flaky call to that service fails the whole step and cascades to
every dependent build job. The action retries the blob download but not
the signed-URL request, and it exposes no retry option.

## What

Since a JS `uses:` step can't be looped inside a composite action, the
single download step in `DownloadProjectDependencies/action.yaml` is now
a 3-attempt chain:

- Attempt 1 runs with `continue-on-error: true`.
- If it fails, wait 30 seconds, then Attempt 2 (also `continue-on-error:
true`).
- If that fails too, wait another 30 seconds, then Attempt 3, which has
no `continue-on-error` so it fails the job normally.

The retry conditions gate on `steps.<id>.outcome == 'failure'` (the
result before `continue-on-error` is applied), so a real failure
correctly triggers the next attempt. The job fails only if all 3
attempts fail; when an attempt succeeds, the remaining attempts are
skipped, so the happy path adds no time.

## Notes

- This is a mitigation for flaky infrastructure, not a code bug. A more
durable follow-up would replace this JS action with AL-Go's own
resilient PowerShell downloader (`DownloadArtifact` /
`InvokeWebRequest`, which hits the REST `archive_download_url` directly
and already retries), used everywhere else for dependency downloads.
- On a retry, the full matched artifact set is re-downloaded, including
any that already succeeded. It's idempotent, just slightly redundant
bandwidth on the uncommon retry path.