Drop daily quality from release/10.0 and 10.0 channels

[LoopedBard3]

After .NET 10 GA, -Quality daily on the release/10.0 (and bare 10.0) channels resolves to internal-only servicing SDK builds (e.g. SDK 10.0.9-flavored bits) whose matching Microsoft.NETCore.App.Runtime.<rid> runtime pack has not yet shipped publicly on the dotnet10 / dotnet-public NuGet feeds.

That breaks the CertHelper --self-contained publish in run_performance_job.py:

performance\src\tools\CertHelper\CertHelper.csproj : error NU1102:
  Unable to find package Microsoft.NETCore.App.Runtime.win-x64
  with version (= 10.0.9)

(Example failing run: https://dev.azure.com/dnceng/internal/_build/results?buildId=2969704)

Fix

Remove 'quality': 'daily' from the release/10.0 and 10.0 entries in channel_map.py. With no quality specified, dotnet.py omits the -Quality flag (it already handles None correctly), so dotnet-install hits the public aka.ms/dotnet/10.0/ GA endpoint — currently SDK 10.0.203 / runtime 10.0.7 — whose runtime packs are publicly available, so the publish step succeeds and the SDK rolls forward automatically with each public servicing release.

What's unchanged

• main (net11) stays on quality: daily — net11 is pre-release and its dailies are public, so that's still the right choice.
• nativeaot10.0 is unchanged in this PR but has the same shape (branch: 10.0, quality: daily) and would hit the same NU1102 if exercised today. Happy to fold it in if reviewers prefer; left out for now since it's not the failing path.
• No changes to sdk-perf-jobs.yml; this is purely a fix for runs that already use release/10.0 / 10.0.

Trade-off

The net10 leg now baselines against the latest publicly-released servicing build (e.g. runtime 10.0.7) instead of the freshest internal daily. For BDN regression work this is actually the more reproducible baseline; runtime perf jobs that build their own Core_Root use the SDK only as build-time tooling, so a slightly older public SDK is fine.

Validation

Verified manually by triggering perf runs from this branch against release/10.0 and confirming the CertHelper publish succeeds and the runs upload results end-to-end.

[Copilot]

Pull request overview

This PR updates the runtime channel configuration used by the repo’s tooling so that .NET 10 jobs no longer request internal-only “daily” servicing SDK builds after .NET 10 GA, avoiding restore/publish failures (e.g., missing runtime packs on public feeds).

Changes:

• Removed quality: 'daily' from the 10.0 channel entry.
• Removed quality: 'daily' from the release/10.0 channel entry.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

[DrewScoggins]

The one issue I have here is that we are no longer going to be testing the servicing bits before they are released. Now, I could believe that because we had never really had consistent darc updates to ensure that we had the correct feeds, we were not testing the correct thing before. But this is a shift in what we intend to test. I don't think that we should not merge this, but it will be different than what we were doing before, from a policy level.

[LoopedBard3]

We were never testing servicing bits before release, the pipeline is setup to run against release/10.0 but that doesn't get prerelease servicing bits AFAIK. If we want to be testing servicing bits before they are released we need to revisit what we are running against and how we get all of the bits.

[LoopedBard3]

Talked offline and clarified that we are testing pre-release release/10.0 bits and that this PR only impacts the SDK we use and the packages that are used when building/running (so we don't rely on not yet published versions).