`Install-PSResource`/`Save-PSResource` silently installs the `-beta` prerelease package instead of the requested stable version when both exist in the feed

[urkon]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest released version
• Search the existing issues.

Steps to reproduce

Register-PSResourceRepository -Name TestRepo -Uri 'https://<nuget-v3-feed>/index.json' -Trusted

# No -Prerelease switch, exact stable version requested
Save-PSResource -Name My.Module -Version '0.0.4' -Repository TestRepo -Path C:\temp\save -Verbose
# Same result with a range instead of an exact version:
Save-PSResource -Name My.Module -Version '[0.0.4]' -Repository TestRepo -Path C:\temp\save -Verbose

Verbose/debug output during resolution correctly parses the target as 0.0.4, but the actual download call fetches the -beta package:

DEBUG: Package version parsed as '0.0.4' satisfies the version range
VERBOSE: Performing the operation "Install-PSResource" on target "Package to install: 'My.Module', version: '0.0.4'".
DEBUG: In V3ServerAPICalls::HttpRequestCallForContent()
DEBUG: Request url is '.../packages/nuget/download/My.Module/0.0.4-beta/my.module.0.0.4-beta.nupkg'

Expected behavior

`Save-PSResource`/`Install-PSResource -Version '0.0.4'` (no `-Prerelease`) should download and install the **stable** `0.0.4` package — the one whose own metadata/nuspec version is `0.0.4` with no prerelease label — since a stable version satisfying the request exists in the feed.

Actual behavior

The cmdlet reports/logs version `0.0.4`, but downloads and installs the **`0.0.4-beta`** package instead. This was confirmed by comparing the two packages directly:

| | Stable (`0.0.4`) | Prerelease (`0.0.4-beta`) |
|---|---|---|
| Direct download URL | `.../download/My.Module/0.0.4/my.module.0.0.4.nupkg` | `.../download/My.Module/0.0.4-beta/my.module.0.0.4-beta.nupkg` |
| `.nuspec` `<version>` | `0.0.4` | `0.0.4-beta` |
| Manifest `ModuleVersion` | `0.0.4` | `0.0.4` |
| Manifest `PrivateData.PSData.Prerelease` | *(unset)* | `beta` |
| Size | 78,558 bytes | 78,537 bytes |
| SHA256 | `FFC470442D806FB8EFCBE5B08A6A97384CF69C50EC8AE09C90814FE25C26FD38` | `9BB45237A2D8AD41FB1DB36F8DE236AD6729726C6B75C19A3B3548B0BCBB196D` |

After running `Save-PSResource -Name My.Module -Version '0.0.4'` (no `-Prerelease`), the saved manifest is:


ModuleVersion=0.0.4
PrivateData.PSData.Prerelease=beta


i.e. content identical to the `0.0.4-beta` package, not the stable one, even though no `-Prerelease` switch was used and an exact stable version was requested.

`Find-PSResource -Name My.Module -Version '0.0.4'` (or `'[0.0.4]'`) still reports the resolved version as plain `0.0.4` — the mismatch only becomes visible by inspecting the installed/saved package's own content, not from the cmdlet's own version output.

Error details

## Prerequisites

- [x] Reproduced on the latest released version (`Microsoft.PowerShell.PSResourceGet` 1.2.0)
- [x] Searched existing issues — related but distinct from [#1247](https://github.com/PowerShell/PSResourceGet/issues/1247) (that issue is about a package with *no* stable version at all being blocked without `-Prerelease`; here a stable version *does* exist and is silently swapped for a prerelease one instead of being installed or blocked)

## Environment

- `PSResourceGet`: 1.2.0
- PowerShell: 7.6.5 (Core)
- Repository type: NuGet v3 protocol feed hosted on a private package registry (`My.Repo`)
- Package: `My.Module`, feed contains:
  - `0.0.4` (stable)
  - `0.0.4-beta`
  - `0.0.3-beta`
  - `0.0.2-beta`

## Root cause hypothesis

The registration/service-index metadata for the package is correct and unambiguous — the registration entries for `0.0.4` and `0.0.4-beta` point at two different, correctly-versioned `.nupkg` files. The bug appears to be in `V3ServerAPICalls` version selection during install: it appears to satisfy the requested version range against `0.0.4` for logging/verification purposes, but then constructs/selects the actual download URL using the highest catalog entry it iterates over (which lands on `0.0.4-beta`, likely because prerelease/stable identifiers with the same core version (`0.0.4` vs `0.0.4-beta`) aren't being disambiguated correctly when picking which entry's `packageContent` to fetch).

## Impact

This is more severe than #1247: instead of failing loudly or requiring `-Prerelease`, the cmdlet silently installs prerelease content while reporting a stable version, with no warning or error. Consumers pinning to an exact stable version (e.g. in CI/CD publishing pipelines) can end up running prerelease code without any indication.

## Workarounds

- Remove/unlist the prerelease version once its corresponding stable version is published (only one version per major.minor.patch core in the feed at a time).
- Bypass the resolver: download the stable `.nupkg` directly from its known `packageContent` URL and install manually.

Environment data

Get-Module Microsoft.PowerShell.PSResourceGet; $PSVersionTable

ModuleType Version    PreRelease Name                                ExportedCommands
---------- -------    ---------- ----                                ----------------
Binary     1.2.0                 Microsoft.PowerShell.PSResourceGet  {Compress-PSResource, Find-PSResource, Get-InstalledPSResource, Get-PSResourceRepository…}

Key   : PSVersion
Value : 7.6.4
Name  : PSVersion


Key   : PSEdition
Value : Core
Name  : PSEdition


Key   : GitCommitId
Value : 7.6.4
Name  : GitCommitId


Key   : OS
Value : Ubuntu 24.04.4 LTS
Name  : OS


Key   : Platform
Value : Unix
Name  : Platform


Key   : PSCompatibleVersions
Value : {1.0, 2.0, 3.0, 4.0…}
Name  : PSCompatibleVersions


Key   : PSRemotingProtocolVersion
Value : 2.4
Name  : PSRemotingProtocolVersion


Key   : SerializationVersion
Value : 1.1.0.1
Name  : SerializationVersion


Key   : WSManStackVersion
Value : 3.0
Name  : WSManStackVersion

Visuals

No response

[urkon]

Also, I can install some other version instead of the specified one by calling:
Install-PSResource My.Module -Version 0.0.3-dev.123

It will always take the highest prerelease (e.g., 0.0.3-dev.333) and log a warning:
WARNING: Resource 'My.Module' with version '0.0.3-dev.123' is already installed. ...
Even if the module with the given version is not installed.

That version can not be installed at all. It always takes the version '0.0.3-dev.333' instead.
The version pinning is broken for the prerelease versions.