DotNetRuntimeValidation nonshipping archives lose build suffix in stable builds

### Description

`DotNetRuntimeValidation` is a nonshipping asset, but its archive filename directly concatenates `VersionPrefix` and `VersionSuffix`:

https://github.com/dotnet/deployment-tools/blob/main/src/DotNetRuntimeValidation/Directory.Build.targets

```xml
DotNetRuntimeValidation-$(VersionPrefix)-$(VersionSuffix)-win-$(TargetArchitecture).zip
```

When deployment-tools is built with stable/stabilized product versioning, `VersionSuffix` is empty. This produces names such as:

- `assets/x86/DotNetRuntimeValidation-10.0.0--win-x86.zip`
- `assets/x64/DotNetRuntimeValidation-10.0.0--win-x64.zip`
- `assets/arm64/DotNetRuntimeValidation-10.0.0--win-arm64.zip`

These entries appear in the manifests from [VMR build 3049220](https://dev.azure.com/dnceng/internal/_build/results?buildId=3049220), with `RepoOrigin=deployment-tools`, `NonShipping=true`, and the corresponding `Windows_*_Artifacts` origin.

This bypasses the repository's nonshipping-aware version flow: [`Directory.Build.targets`](https://github.com/dotnet/deployment-tools/blob/main/Directory.Build.targets) sets `IncludePreReleaseLabelInPackageVersion=true` when `IsShipping != true`. A deployment-tools package in the same manifest is correctly unique (`Microsoft.Deployment.DotNet.Releases.2.0.0-rtm.1.26416.102.nupkg`), while the validation archive has no build suffix.

### Impact

The empty suffix emits a double separator and, more importantly, gives every stable build the same archive name/version. This creates collisions between builds; examples include [build 3030876](https://dev.azure.com/dnceng/internal/_build/results?buildId=3030876) and [build 3049329](https://dev.azure.com/dnceng/internal/_build/results?buildId=3049329).

### Regression timing

- Before stabilization, VMR build `20260417.14` produced `DotNetRuntimeValidation-10.0.0-preview.1.26217.114-win-x64.zip`.
- [dotnet/dotnet#5854](https://github.com/dotnet/dotnet/pull/5854), merged 2026-04-22, reset deployment-tools to stable build 306729 / [deployment-tools commit 95a979e](https://github.com/dotnet/deployment-tools/commit/95a979e12bf2a7707a29954612508b2a0ef3d42c), exposing the filename/property issue under `rtm` / `StabilizePackageVersion=true` versioning.
- The earliest archived affected manifest found is VMR build `20260428.18`, with `DotNetRuntimeValidation-10.0.0--win-x64.zip`.

### Expected behavior

Nonshipping `DotNetRuntimeValidation` archive names should retain a unique prerelease/build suffix even when the repository/product build is stable, and should never emit an empty `--` separator.

The filename likely needs to consume the nonshipping-aware evaluated version rather than directly concatenating `VersionPrefix`/`VersionSuffix`; the exact property and target evaluation ordering should be validated in the fix.

Start with src/DotNetRuntimeValidation/Directory.Build.targets and compare its archive-name inputs with the nonshipping version flow in Directory.Build.targets. Validate the evaluated properties and target ordering for stable and prerelease builds. Done means stable nonshipping archives have a unique build suffix and never contain an empty `--` separator.

Written by the indexing model from the issue text.