Arm backend: fix unbound ARM_SETUP_CURL_PROGRESS_ARGS under bash 3.2

[synath]

Summary

Fixes #22313

examples/arm/setup.sh runs under set -u, but ARM_SETUP_CURL_PROGRESS_ARGS
is only assigned when .ci/scripts/detect_ci.sh detects a CI environment. On a
local run the array is never set, and the first download aborts on macOS's
stock bash:

backends/arm/scripts/utils.sh: line 96: ARM_SETUP_CURL_PROGRESS_ARGS[@]: unbound variable

CI never sees this because bash >= 4.4 expands an unset array under set -u
without error; macOS ships bash 3.2.57.

This PR guards the three expansion sites (utils.sh:download_with_retry, and
the two curl calls in vulkan_utils.sh) with the portable idiom:

${ARM_SETUP_CURL_PROGRESS_ARGS[@]+"${ARM_SETUP_CURL_PROGRESS_ARGS[@]}"}

Why not just initialize the array to () near the top of setup.sh: bash
before 4.4 raises the same error when expanding an empty array under
set -u, so that would still crash on macOS. The + parameter-expansion
guard handles unset and empty alike, and preserves per-element quoting when
the array is populated (the CI case).

Test plan

Manual, on macOS 26 / stock /bin/bash 3.2.57. Reproduce each state of the
array against both the old and the guarded expansion (printf standing in
for curl):

# old form — errors when unset, errors when empty, OK when set:
/bin/bash -uc 'printf "<%s>" x "${A[@]}" y'                  # error: A[@]: unbound variable
/bin/bash -uc 'A=(); printf "<%s>" x "${A[@]}" y'            # error: A[@]: unbound variable
/bin/bash -uc 'A=(--no-progress-meter); printf "<%s>" x "${A[@]}" y'   # <x><--no-progress-meter><y>

# guarded form — OK in all three states, quoting preserved:
/bin/bash -uc 'printf "<%s>" x ${A[@]+"${A[@]}"} y'          # <x><y>
/bin/bash -uc 'A=(); printf "<%s>" x ${A[@]+"${A[@]}"} y'    # <x><y>
/bin/bash -uc 'A=(--no-progress-meter); printf "<%s>" x ${A[@]+"${A[@]}"} y'   # <x><--no-progress-meter><y>

Also verified: identical guarded-form behavior on bash 5.3 (no regression for
Linux/CI), and bash -n syntax checks pass on both edited scripts under both
bash versions.

---

Developed with Claude's assistance (co-author trailer on the commit); diagnosed
on my machine while working through the Ethos-U getting-started tutorial, and
verified by me on macOS 26 / stock bash 3.2.57.

cc @digantdesai @freddan80 @per @zingo @oscarandersson8218 @mansnils @Sebastian-Larsson @robell @rascani

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/22337

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 2 New Failures, 1 Unrelated Failure, 1 Unclassified Failure

As of commit cbb80d1 with merge base d614f9d ():

NEW FAILURES - The following jobs have failed:

• Test RISC-V Backend / test-riscv (yolo26, false, false) / run / linux-job (gh)
  RuntimeError: Command docker exec -t de72f1bcf935aec8f4a723171ee95054a4d748c559f33225bc3f1cdba251ab17 /exec failed with exit code 1
• Test RISC-V Backend / test-riscv (yolo26, true, false) / run / linux-job (gh)
  AssertionError: Expected p_model_model_0_conv_weight to be NCHW in channels last reshape pass

UNCLASSIFIED FAILURE - DrCI could not classify the following job because the workflow did not run on the merge base. The failure may be pre-existing on trunk or introduced by this PR:

• trunk / test-llama-runner-mac (fp32, coreml) / macos-job (gh) (this job did not run on the merge base, so DrCI cannot tell whether the failure is pre-existing)
  AttributeError: 'BackendConfig' object has no attribute 'mps'

FLAKY - The following job failed but was likely due to flakiness present on trunk:

• pull / test-qnn-testsuite-linux / test-backend-linux (qnn, models) / linux-job (gh) (matched linux rule in flaky-rules.json)
  The runner has received a shutdown signal. This can happen when the runner service is stopped, or a manually started runner is canceled.

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[meta-cla]

Hi @synath!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: synath / name: David Turley (cbb80d1)

[pytorch-bot]

Workflows were awaiting approval. CI has now been triggered for the ciflow labels on this PR.

[synath]

@pytorchbot label "release notes: arm"

[meta-cla]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!

[synath]

/easycla

[zingo]

Wow good catch! Thanks for you contribution, I kicked of the GitHub testing :)

[zingo]

OK to merge, let me know if you have problem and I can press the button for you. I'm not 100% sure who have permissions to merge/submit :)

[synath]

Thanks @zingo! Looks like I don't have merge permissions (or the failing CI jobs prevent it? I thought I saw a merge button at some point before CI ran, but there isn't one now), so please go ahead. The CI failures appear unrelated to this minor change. Thanks for letting me pitch in!