chore(ci): Make the install scripts fail on a bad download instead of a checksum mismatch

The three scripts that download a toolchain tarball call `curl` without `--fail`, so an HTTP error response is written to the output file and `curl` exits 0. The checksum check that follows then fails, and the job reports `Checksum failed` for what was really a 503 from the download host.

- `scripts/install_gotestsum.sh` line 22
- `scripts/installgo_linux.sh` line 13
- `scripts/installgo_mac.sh` line 26

None of them pass `--retry` either, so a transient blip on `github.com` or `go.dev` fails the job outright rather than being ridden out.

### What it looked like

During a GitHub download outage on 2026-08-12 around 19:40 UTC this failed six pull requests in a row, on whichever job happened to be running. Two different symptoms, one cause:

`test-go-linux-386` ([job 544263](https://circleci.com/gh/influxdata/telegraf/544263)) downloaded 107 bytes instead of the tarball and reported:

```text
+ curl -L https://github.com/gotestyourself/gotestsum/releases/download/v1.13.0/gotestsum_1.13.0_linux_amd64.tar.gz --output gotestsum.tar.gz
100 107 100 107 0 0 3102 0
+ sha256sum --check -
gotestsum.tar.gz: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match
Checksum failed
```

`test-go-linux` ([job 544215](https://circleci.com/gh/influxdata/telegraf/544215), [job 544237](https://circleci.com/gh/influxdata/telegraf/544237)) lost the connection outright:

```text
curl: (56) Connection died, tried 5 times before giving up
```

The first one is the misleading case. `Checksum failed` on a pinned, long-stable release reads like a tampered or rotated artifact, which is the one thing that would justify stopping everything and looking. It cost a while to work out that the 107-byte "tarball" was an error page.

### Why it is only a diagnosability problem

All three scripts verify the sha256 before extracting, so a bad download is never used. This is not a supply-chain hole, it is a confusing failure mode plus avoidable flakiness.

### Suggested fix

Add `--fail` so an HTTP error is an error, and `--retry` so a transient one is retried:

```sh
curl --fail --retry 3 --retry-delay 5 -L "" --output ""
```

`scripts/install_incus.sh` already uses `curl -fsSL`, so `--fail` is the existing convention in this directory.

Verified locally against a server returning 503, with curl 8.7.1:

| invocation | exit | output file |
|---|---|---|
| `curl -L --output f` (today) | 0 | 58 bytes of error page |
| `curl -fL --output f` | 22 | not created |
| `curl -fL --retry 2 --retry-delay 1 --output f` | 22 after 2s | not created |

The last row confirms `--retry` does treat 503 as transient and retries it, so the outage above would most likely have been ridden out rather than failing six pull requests.

### Out of scope

The `test-go-windows` failures in the same window came from `choco install mingw` hitting a 503 for the mingw-builds release asset. That download belongs to Chocolatey's own install script, not to anything in this repository.

Start by reading scripts/install_gotestsum.sh line 22, scripts/installgo_linux.sh line 13, and scripts/installgo_mac.sh line 26, then compare their curl usage with scripts/install_incus.sh. Verify the download behavior against an HTTP 503 and confirm that transient failures are retried while checksum verification still protects extraction.

Written by the indexing model from the issue text.