WinGet stable Aspire CLI manifest still points at a preview-tagged CI URL

## Description

#20136 reports that installing/updating the stable Aspire CLI through winget downloads from a preview-tagged `ci.dot.net` path even though winget reports a stable version number:

```
Found Aspire CLI [Microsoft.Aspire] Version 13.5.3
Downloading https://ci.dot.net/public/aspire/13.5.3-preview.1.26425.3/aspire-cli-win-x64-13.5.3.zip
```

PR #20168 fixes the equivalent problem for the `get-aspire-cli.sh` / `get-aspire-cli.ps1` script installers (they now resolve the latest stable version via GitHub's release redirect and download from `github.com/.../releases/download/...` instead of the aka.ms channel). It does **not** fix the winget manifest, for a structural reason in the release pipeline, not just build-vs-release timing:

```
Stage: Release
└─ WinGetJob (dependsOn: ReleaseJob) ← generates + submits the WinGet manifest PR here
Stage: GitHubTasks (dependsOn: [Release, PrepareArtifacts])
└─ DispatchGitHubTasksJob ← creates the git tag + DRAFT GitHub Release
└─ PublishReleaseAssetsJob ← uploads aspire-cli-*.zip/tar.gz to the draft
```

(`eng/pipelines/release-publish-nuget.yml`.) `WinGetJob` submits the manifest to `microsoft/winget-pkgs` in the `Release` stage, entirely *before* the `GitHubTasks` stage runs — the GitHub tag/release/assets don't exist yet at that point in the pipeline, regardless of any script-level fix.

It's also not just an ordering problem: the GitHub release is created as a **draft**, and per the pipeline's own comments, draft-release assets are not publicly downloadable until a human (the release manager) manually publishes the draft as a final, unscheduled step (`docs/release-process.md`, "Publish the draft release"). `eng/pipelines/templates/publish-winget.yml` does a live HTTP HEAD reachability check on every `InstallerUrl` before submitting the manifest — pointing it at a GitHub release URL would fail that check on every real stable release until the draft is published, which today happens well after `WinGetJob` runs.

So a real fix needs more than reordering: it needs winget manifest submission to either wait on the manual "publish draft" step, or move to a separate post-publish trigger (comparable to how Homebrew's cask bump is validated by `.github/workflows/homebrew-validate-release.yml` on the `release: [published]` event, after the release manager publishes).

## Expected behavior

The winget manifest for a stable Aspire CLI release should ultimately point at (or otherwise avoid exposing) a preview-tagged storage path, consistent with what `winget show`/`winget upgrade` reports as the package version.

## Suggested next steps

- Investigate restructuring `WinGetJob` to run only after the GitHub release is published (not just created as a draft) — e.g. moving winget submission to a separate stage/workflow gated on `release: [published]`, mirroring the Homebrew autobump/validate flow.
- Alternatively, investigate whether the CI artifact naming itself can avoid embedding a `-preview.*` segment in the path used for what will become the stable release, independent of the winget/script consumption path.
- Either approach needs to account for the release manager's manual "publish draft" step not being scheduled/guaranteed to happen promptly — a design that blocks indefinitely on that step could stall in-flight winget submissions.

Read eng/pipelines/release-publish-nuget.yml and eng/pipelines/templates/publish-winget.yml first, then compare .github/workflows/homebrew-validate-release.yml and the publish-draft section of docs/release-process.md. Determine a post-publication or artifact-path design that does not stall on the manual release step. Done means stable WinGet manifests no longer expose preview-tagged URLs and reachability checks still pass.

Written by the indexing model from the issue text.