Confirmed the bug and the fix - reproduced it in isolation: under set -euo pipefail, a curl failure with no || curl_status=$? guard aborts the whole step on the first bad attempt, never reaching the retry loop. The retry logic only ever worked for corrupted downloads (size/checksum mismatch), never for outright failed ones, which defeats the point of the retry. This fixes exactly that.

curl_status reset each iteration, branch correctly skips reading $zip_path when curl itself failed rather than misreporting it as a size mismatch. Looks good.

Correct fix. set -e combined with curl -fsSL --retry 3 was aborting the step on non-transient errors (mid-transfer resets, exit 56, etc.) before the outer retry loop could react — capturing curl_status via || curl_status=$? puts control back in the loop. Size/checksum verification stays intact.

APPROVE.