[WIP] Fix binary download to include retry logic

[Claude]

Thanks for asking me to work on this. I will get started on it and keep this PR's description up to date as I form a plan and make progress.

---

This section details on the original issue you should resolve

<issue_title>Binary download has no retry</issue_title>
<issue_description>### What version are you using?

stellar/binaries as currently published on main.

What did you do?

Used the action to install prebuilt cargo tools in CI — for example uses: stellar/binaries@v45 with name: cargo-hack and version: 0.5.28 — including in several jobs that gate stellar/rs-soroban-sdk's GitHub merge queue (semver-checks, build, test, build-fuzz, expand-test-wasms). Each invocation downloads the release tarball from GitHub Releases with the single curl command above.

What did you expect to see?

A transient network blip while fetching the release asset — for example a 503 from GitHub Releases or objects.githubusercontent.com — should be retried so it does not fail the build, the same way the rest of the pipeline already rides out transient 5xx (cargo via CARGO_NET_RETRY, and actions/checkout and actions/upload-artifact / download-artifact via their built-in retries).

What did you see instead?

Because the download is a single curl -fL ... | tar xvz with no retry, a transient 503 fails curl, which fails the step and the whole job even though nothing is wrong with the caller's build. In merge-queue builds this fails a required check, and GitHub immediately evicts the pull request from the merge queue; re-queuing a batch of PRs afterward takes real effort, so an arbitrary HTTP blip during a tool download repeatedly knocks PRs out of the queue for reasons unrelated to the change under test.

Suggested fix: give curl its own retry, and download to a file before extracting so a mid-stream failure can be retried cleanly (piping curl | tar can't recover a partially-consumed stream). In the final step of action.yml:

# before
curl -fL https://github.com/stellar/binaries/releases/download/$ref/$file | tar xvz -C $INSTALL_PATH

# after
url="https://github.com/stellar/binaries/releases/download/$ref/$file"
curl --retry 5 --retry-all-errors --retry-delay 2 -fL -o "$RUNNER_TEMP/$file" "$url"
tar xvz -C "$INSTALL_PATH" -f "$RUNNER_TEMP/$file"

--retry handles transient failures and --retry-all-errors ensures HTTP 5xx responses are retried too (which --retry alone treats inconsistently across curl versions). If you'd rather keep the one-liner, curl --retry 5 --retry-all-errors --retry-delay 2 -fL <url> | tar xvz -C $INSTALL_PATH is a smaller change that still retries the request, just without the clean mid-stream recovery the temp-file form gives. Either way it stays tiny and relies on curl's built-in retry rather than any custom retry logic.
</issue_description>

Comments on the Issue (you are @claude[agent] in this section)