dotnet-quality applies to every entry in dotnet-version, so "stable current + preview of next" is not expressible

Description

dotnet-quality is a single input for the whole step, and it applies to every version listed in dotnet-version. That makes a very common combination impossible to express: the current released SDK, plus a preview of the upcoming one.

- uses: actions/setup-dotnet@v6
  with:
    dotnet-version: |
      10.0.x
      11.0.x
    dotnet-quality: preview

The intent here is "released 10.0, preview 11.0". What actually happens is that both are resolved at preview quality:

install-dotnet.ps1 -SkipNonVersionedFiles -Channel 10.0 -Quality preview
dotnet-install: .NET Core SDK with version '10.0.100-rc.2.25502.107' is already installed.

install-dotnet.ps1 -SkipNonVersionedFiles -Channel 11.0 -Quality preview
dotnet-install: .NET Core SDK with version '11.0.100-preview.7.26381.103' is already installed.

Even though 10.0 has shipped, the 10.0 request resolves to a release candidate. Combined with the "is already installed" short-circuit, a runner that once had the RC never moves to the released SDK.

Why we want both

We build against the current released SDK, and additionally install the next preview to compile a small amount of code with the upcoming C# language preview features (<LangVersion>preview</LangVersion>). That is a normal thing to want: production builds on the stable toolchain, plus early exposure to the next language version. It is not "give me previews of everything".

Impact beyond picking the wrong SDK

The knock-on effect is easy to miss. Because no released 10.0 SDK is ever installed, the only Microsoft.WindowsDesktop.App runtimes present are the prerelease ones bundled with the RC and the next preview:

Framework: 'Microsoft.WindowsDesktop.App', version '10.0.0' (x64)
The following frameworks were found:
  10.0.0-rc.2.25502.107
  11.0.0-preview.7.26381.103

A WPF test host targeting net10.0-windows asks for GA 10.0.0 and will not roll forward onto a release candidate, nor across a major version, so it fails to launch. The build still succeeds, because selecting an SDK and finding a matching runtime are different things - which makes this fail late and confusingly.

Workaround

Two steps, which works but is more verbose and easy to get wrong:

- uses: actions/setup-dotnet@v6
  with:
    dotnet-version: 10.0.x

- uses: actions/setup-dotnet@v6
  with:
    dotnet-version: 11.0.x
    dotnet-quality: preview

Possible resolutions

1. Allow quality to be attached per version, for example 11.0.x:preview alongside a plain 10.0.x.
2. Accept a matching list for dotnet-quality, aligned by position with dotnet-version.
3. At minimum, document clearly that dotnet-quality is step-wide and that mixing qualities requires separate steps - the current README reads as though it qualifies each requested version.

Option 1 seems the smallest change for callers and keeps everything in one step.

Start with the README's documentation of dotnet-version and dotnet-quality, then trace how those inputs are handled by the action. Done means one step can request released 10.0 and preview 11.0 independently, while the existing separate-step workaround and runtime behavior remain correct.