ci(s3): use curl -fLO to follow redirect when downloading mc

[XuQianJin-Stars]

The previous 'curl -O' did not follow HTTP redirects, so only a 141-byte redirect HTML body was saved as 'mc', causing:

./mc: line 1: a: No such file or directory

Adding -L makes curl follow the redirect and download the real binary, while -f makes curl fail fast on HTTP errors.

Which issue does this PR close?

Closes #.

Rationale for this change

The MinIO anonymous S3 behavior test (.github/services/s3/minio_s3_with_anonymous/action.yml) downloads the MinIO client (mc) from https://dl.min.io/client/mc/release/linux-amd64/mc with curl -O.
dl.min.io now responds with an HTTP 302 redirect to a CDN URL. Because curl -O does not follow redirects by default, only the 141-byte redirect HTML body is saved as mc. When the shell then tries to execute ./mc, it is parsed as a script instead of a binary and fails with:

./mc: line 1: a: No such file or directory
##[error]Process completed with exit code 1.

This breaks the s3 / minio_s3_with_anonymous behavior test job in CI.

What changes are included in this PR?

A single one-line change in .github/services/s3/minio_s3_with_anonymous/action.yml:

-        curl -O https://dl.min.io/client/mc/release/linux-amd64/mc
+        curl -fLO https://dl.min.io/client/mc/release/linux-amd64/mc

-L: follow HTTP redirects so the real mc binary is downloaded.
-f: fail fast with a non-zero exit code on HTTP errors, so future breakage surfaces immediately at the download step instead of in a later ./mc: line 1: ... error.

Are there any user-facing changes?

No. This is a CI-only change. It does not touch any library code, public API, runtime behavior, or documentation shipped to users.

AI Usage Statement

This PR was prepared with assistance from an AI coding agent:
The agent identified the root cause (missing -L causing only the redirect body to be saved) from the CI failure log.
The agent made the one-line change to action.yml and wrote the commit message and this PR description.
All changes were reviewed by the author before pushing and opening this PR.

[TennyZhuang]

Staging regression team independently identified the same root cause during our CI sweep: curl -O saves the 141-byte HTTP 302 redirect body instead of following to the actual binary.

Confirmed locally:

• Plain curl -O → 141 bytes (HTML redirect)
• curl -fLO → downloads the real ELF binary

LGTM on the fix. The -L flag is the minimal correct change, and -f + set -e ensures future download failures surface immediately at the curl step rather than with the cryptic ./mc: line 1: a: No such file or directory error.

[TennyZhuang]

Cross-review by @clara-claude-pyreview-719124 (staging regression):

This PR solves the same root cause as our staging PR #7454 (now closed as duplicate). The fix is correct: curl -fLO follows the HTTP 302 redirect and fails fast on errors.

Evidence: https://dl.min.io/client/mc/release/linux-amd64/mc returns HTTP 302 with a 141-byte HTML body without -L. With -L, it downloads the 29MB ELF binary correctly.

LGTM — recommend merging this over #7454.