Prepare the Aspire CLI bundle once before the CI build, so parallel AppHost builds no longer race to download it

[Vulthil]

Summary

CI on main has failed since the Aspire 13.6.0 update (#421), with
ASPIRE009: … Automatic Aspire CLI bundle setup failed with exit code 1 in
Vulthil.Messaging.IntegrationTest.AppHost.

Cause

• The Aspire CLI bundle cache key hashes global.json, so the Aspire bump made the cache miss, and the build had
  to prepare the bundle itself.
• Each AppHost project prepares a missing bundle during its own build (dnx --yes aspire.cli@13.6.0 -- setup). The
  solution has two AppHosts (samples/AppHost and the messaging integration-test AppHost), and the build runs them
  in parallel.
• Two dnx runs at once download the same aspire.cli package into the NuGet cache, and one of them fails with
  "The process cannot access the file '…/aspire.cli.13.6.0.nupkg' because it is being used by another process"
  (exit code 1).
• Aspire 13.6.0 itself is fine: one setup on a fresh home succeeds.

Fix

• setup-build prepares the bundle in its own step on a cache miss, in one process, with the CLI version from
  Aspire.AppHost.Sdk in global.json (the version the build asks for). The AppHost builds then find the bundle
  and never run the setup, and the setup's own output shows in the CI log.

Verification

• Reproduced on Linux (WSL, .NET SDK 10.0.401, fresh home): two concurrent
  dnx --yes aspire.cli@13.6.0 -- setup --install-path ~/.aspire runs → one exits 0, the other exits 1 with the
  NuGet-cache "being used by another process" error. One run alone exits 0.
• Ran the new step's exact command the same way: exit 0, and ~/.aspire/bundle and ~/.aspire/versions/13.6.0_…
  (the cached paths) are created.
• This PR's own CI run misses the bundle cache, so it runs the new step before the build.

Backport to v1.0: no