Consider NativeAOT-publish lane in stabilization_check CI job

Follow-up to #15681 / #15335.

The new `stabilization_check` job in `ci.yml` runs `./build.sh -pack /p:StabilizePackageVersion=true /p:SkipNativeBuild=true` to keep the PR-time cost down (~5 min). It invokes the CLI via `dotnet run --project src/Aspire.Cli/Aspire.Cli.csproj` for the `aspire init` + `aspire restore` smoke (see `eng/scripts/stabilization-smoke-init-restore.sh`).

That gives us coverage of the managed CLI code path under stabilization but not the **NativeAOT-published** CLI binary that ships to users. NativeAOT publishes can occasionally surface different behavior than `dotnet run`-mode (trimming-related code paths, AOT linker behavior, runtime-mode differences). Today these are validated only by `.github/workflows/build-cli-native-archives.yml`, which doesn't pack under stabilization.

**Options to consider:**

1. Add a second, more expensive CI lane that does a NativeAOT publish for one RID (e.g. `linux-x64`) under `StabilizePackageVersion=true` and runs the smoke against the published binary. Cost: roughly +10 min per PR on the long pole.
2. Extend `build-cli-native-archives.yml` to also produce a stabilized native CLI artifact as a separate matrix entry and have a downstream smoke pull it.
3. Status quo + accept the gap (stabilization-time AOT-specific issues only surface in the stabilization PR itself).

Tracking as a backlog item — not blocking for #15681. Revisit if we see concrete stabilization escapes that are AOT-specific.

Originally raised as Q2 / NativeAOT consideration in the discussion on #15681.