fix(e2e): runtime.aspire-restore intermittently hangs 15min to timeout against NuGet feeds — 3 occurrences in one day, local and cloud

[rickylabs]

Three occurrences on 2026-08-04, identical signature — aspire restore (CLI 13.4.6) hangs in its bundled nuget restore of the pinned Aspire.Hosting 13.4.6 packages until the suite's 900s gate timeout, twice per run (retry included), exit 6 Failed to prepare AppHost server:

1. Local WSL, scaffold.runtime proof run ~09:26–09:58Z (aspire logs cli_20260804T092654/094300): restore against api.nuget.org + pkgs.dev.azure.com/dnceng hung; feeds probed sub-second minutes later.
2. Local WSL retry, same class (earlier run of the same morning).
3. Cloud: canary.6's pinned production E2E (run 30906657319, job failed 12:29Z) — FAILED GATE: runtime.aspire-restore, attempt durations: 900.1s + 900.1s, Summary passed=29 failed=1. This turned the canary.6 pair red on a train with no restore-related changes.

Why it matters

The gate spends 30 minutes to report an infra hang, and a single flaky feed window kills an otherwise-green canary pair. Restore is pure infrastructure — it runs before any NetScript code.

Fix shape (decide in slice)

• Shorter per-attempt timeout with more retries (e.g. 3×300s) so transient feed hangs don't consume the gate budget.
• Pre-seeded/offline NuGet package cache for the pinned Aspire.Hosting versions (they are exact-version pins — cacheable by definition), with network restore as fallback.
• Classify the failure distinctly (failureClass: canceled today reads as generic) so canary tooling can mark infra-red vs train-red.

Acceptance

• A hung feed no longer consumes 30 minutes before failing the gate.
• The pinned Aspire.Hosting packages restore from cache when the network feed stalls (or an equivalent mitigation, decided and documented).
• Restore-infra failures are distinguishable from product failures in the suite summary.

[rickylabs]

Reopening: bounded, but not eliminated — and it is now the wave-6 pilot's only red box.

The fix works as designed on the bounding half. Across two consecutive quickstart.walk runs against published 0.0.5-canary.10:

• Run 30959430176 — step 4 (aspire restore + start): PASS in 22.3s
• Run 30961102523 — step 4: FAIL in 180.1s, aspire restore failed (6): Failed to prepare: A task was canceled / Failed to prepare AppHost server

So the 2×900.1s / 30-minute hang that destroyed canary.6 and canary.9 is gone — it now fails in three bounded minutes with a clear error. That is a real improvement and worth keeping. But the underlying restore failure is still occurring, intermittently, roughly one run in two on a clean cloud runner.

Why this is the decisive item rather than a nuisance: step 4 is where an unattended agent following the Quickstart stops. A ~50% failure rate at step 4 means half of all pilot runs halt before the agent writes a line of product code, with an error that reads like their environment is broken. Bounding converted a 30-minute hang into a 3-minute halt; it did not convert a halt into progress.

Remaining scope (the part the retry budget and cache were meant to cover):

• Establish whether the cancellation is NuGet/feed latency, a container-runtime race, or an Aspire CLI defect — the log path ~/.aspire/logs/cli_*.log is captured on the runner and should be surfaced as an artifact
• Retry the restore on this specific failure signature rather than failing the walk on first occurrence
• Pin/cache the Aspire SDK packages so a cold feed cannot fail the step
• Demonstrate the fix by running the walk N consecutive times green, not once

Evidence artifacts: both runs above, same published version, same runner class, opposite outcomes.