Unstable installer URLs cause perpetual hash mismatch failures

## Summary

Publishers overwrite release binaries at the same URL (vanity/unstable URLs), causing the installer hash to change frequently. This creates a cycle where:

1. The automation bot detects the hash mismatch and submits a PR with the new hash
2. By the time the validation pipeline runs (hours later), the publisher has replaced the binary again
3. The pipeline's Installers Scan step fails with "Specified hash doesn't match"
4. The bot detects the mismatch again and creates another PR — cycle repeats indefinitely

## Impact

- Perpetually failing bot PRs that will never pass validation
- Merged manifests with stale hashes that cause install failures for users (`winget install` will fail hash verification)
- Wasted pipeline compute on PRs that cannot succeed

## Affected Packages (Examples)

| Package | URL Type | Behavior |
|---------|----------|----------|
| Okabe-Rintarou-0.SJTUCanvasHelper | GitHub release (re-tagged) | Binary changes with each CI build pushed to same tag |
| AnInsomniacy.MotrixNext | GitHub release | Same |
| axpnet.AeroFTP | GitHub release | Same |
| IvanCharapanau.Harbor | GitHub release | Same |
| PostgreSQL.psqlODBC | GitHub release | Same |
| MoeruAI.AIRI | GitHub release | Same |
| Neovim.Neovim.Nightly | GitHub nightly release | By design — nightly builds overwrite |
| Abnerla.AI_paper | GitHub release | Same |
| IvyScience.ivySCI | CDN | Binary replaced at same URL |
| Folge.Folge | CDN | Same |
| Fiorilli.FiorilliWebExtensionClient | CDN | Same |

## Possible Mitigations

- **Pipeline-level:** If hash mismatch is detected at Installers Scan, re-hash the downloaded binary and compare against the PR's proposed hash at download time (not against the merged manifest). If the URL serves a different binary than what the bot computed, fail fast with a clear "unstable URL" label rather than generic hash mismatch.
- **Bot-level:** Detect repeatedly-failing hash updates for the same version and stop retrying after N attempts. Apply a label like `Unstable-URL` so maintainers can triage differently.
- **Manifest-level:** Require or encourage publishers to use versioned/pinned URLs (e.g., `/download/v1.0.0/app-v1.0.0.exe`) rather than overwriting the same artifact. Consider a manifest field or documentation guidance for URL stability expectations.
- **Policy-level:** Consider removing manifests with known-stale hashes from the index, or marking them with a warning, so users aren't served broken installs.

## Related PRs (perpetually failing)

- https://github.com/microsoft/winget-pkgs/pull/376233
- https://github.com/microsoft/winget-pkgs/pull/376230
- https://github.com/microsoft/winget-pkgs/pull/378832
- https://github.com/microsoft/winget-pkgs/pull/377408
- https://github.com/microsoft/winget-pkgs/pull/376894
- https://github.com/microsoft/winget-pkgs/pull/376862
- https://github.com/microsoft/winget-pkgs/pull/376210
- https://github.com/microsoft/winget-pkgs/pull/376229
- https://github.com/microsoft/winget-pkgs/pull/376176
- https://github.com/microsoft/winget-pkgs/pull/378853
- https://github.com/microsoft/winget-pkgs/pull/378264

No repository files or tests are named. Start by reviewing the Installers Scan failures and the related pull requests listed in the issue, then identify which mitigation maintainers select. Done would require an agreed behavior for unstable URLs, such as detection, retry limits, labeling, or publisher guidance, with validation that the failure is handled as intended.

Written by the indexing model from the issue text.