aka.ms install-script vanity links are not documented and can lag main by several releases

## Summary

`https://aka.ms/aspire/get/install.sh` and `install.ps1` are the URLs documented and used everywhere (README, docs, `get-aspire-cli.ps1`/`.sh` self-referencing usage comments) for installing the Aspire CLI. They are vanity redirects, not a pointer to `main` or to "latest release" — and nothing in this repo's release pipeline (`eng/pipelines/`, `docs/release-process.md`) documents or automates how/when they get repointed.

## Evidence

As of this writing:

```
$ curl -sSLI https://aka.ms/aspire/get/install.sh
...
Location: https://ci.dot.net/public/aspire/13.4.0-preview.1.26277.9/get-aspire-cli.sh
```

`main` is currently on `13.6.0-preview.1` (`eng/Versions.props`), and diffing the script served at that pinned `ci.dot.net` path against the script on `main` shows it is missing multiple already-merged features (e.g. the install-provenance sidecar / channel persistence work from #19469), not just unreleased work. So the aka.ms link can silently lag `main` by several releases with no visibility into when it was last updated or by whom.

`docs/release-process.md`'s installer-channel table says of the install script: *"No separate publication — the script downloads directly from the GitHub release assets attached in Step 1."* That's accurate for the **archive the script downloads**, but says nothing about how the **script itself** gets from a signed build's blob path onto the aka.ms vanity URL that users and docs actually reference.

## Impact

- A merged fix to `get-aspire-cli.sh`/`.ps1` (e.g. #20168) does not reach real users via the documented one-liner install command until someone manually repoints the aka.ms link to a build containing that commit — but there's no documented process, owner, or automation for that step, so it's easy to forget or to not realize it's even required.
- There's no way to tell, without directly curling the redirect, which build's script version aka.ms is currently serving.

## Suggested follow-up

- Document (in `docs/release-process.md` or a dedicated doc) who owns the aka.ms link redirects, what they should point to, and when/how they get updated as part of a release.
- Consider automating the repoint as part of the release pipeline (e.g. update it alongside the WinGet/Homebrew/Nix steps already automated there), or at minimum add a release-checklist reminder.
- Consider whether the redirect should track "latest stable release" dynamically instead of being a manually-pinned per-build blob path, to avoid drift entirely.

Start with docs/release-process.md and the related pipelines under eng/pipelines/. Check the current aka.ms redirect with curl, compare its target script with main, and review eng/Versions.props for the release versions involved. Done means the repository clearly records redirect ownership, target selection, and update timing, or identifies the release-pipeline/checklist change needed to prevent drift.

Written by the indexing model from the issue text.