Add retries to the install action for resilience

[leighmcculloch]

What

Make the stellar/stellar-cli install action resilient to transient network failures during the binary download.

The curl call that fetches the release tarball now retries up to 5 times with backoff (--retry 5 --retry-delay 5 --retry-connrefused --retry-all-errors), bounded by --connect-timeout 30 and --max-time 300. The download now writes to a fixed file in $RUNNER_TEMP and is extracted by tar afterwards, rather than piping curl straight into tar, so that a retried transfer can safely restart without corrupting the tar stream. Using a fixed local filename also keeps the download path independent of the (untrusted) version string.

Why

A single transient network blip previously failed the whole job — for example this rs-soroban-sdk run failed during the install step. With retries in place, a momentary failure is retried instead of failing the build.

This mirrors the approach taken in stellar/actions#104, which added curl's built-in retry flags to harden a similar download path.

Notes

The gh attestation verify step is intentionally left unchanged: the gh CLI already retries attestation fetches internally (up to 3 times on 5xx responses), so a separate retry loop there added little.

[Copilot]

Pull request overview

This PR hardens the repository’s composite GitHub Action (action.yml) that installs stellar-cli, improving CI resilience by retrying network-dependent steps (binary download and attestation verification) instead of failing on transient errors.

Changes:

• Switch the binary download from curl | tar to curl (with retries/timeouts) downloading into a temp file, then extracting via tar.
• Wrap gh attestation verify in a 5-attempt retry loop with exponential backoff.