Update OS Coverage

Update OS version references in Helix queue definition files. These files control which operating system versions are used for CI/CD testing via Helix.

Prerequisites

Baseline build not required: This skill is for YAML/docs-style queue and image reference updates, not product code changes. Do not start with the repo-wide baseline build workflow from copilot-instructions.md unless the task expands beyond image / queue metadata into code changes that actually need build or test validation.

When to use

• An OS version is approaching or has reached EOL and should be replaced
• A new OS version is released and should be added to Helix testing for coverage
• We take a more proactive approach on main. If a distro version will be EOL before our annual November release, we should update it to a newer version. If a distro version is expected to ship within one quarter (3 months) and a prereqs container image already exists, we should add it to Helix testing.
• The availability of an image in the prereqs container repo is a strong signal that the OS version is approved for Helix testing, at least on main.
• Helix coverage does not match the supported-os matrix (for example, the relevant release-notes/<dotnet-version>/supported-os.json file in dotnet/core).
• Upgrading "oldest" or "latest" version slots for a distro

For servicing / release/* branches, be more conservative: only update to GA and already-supported distro versions unless the user explicitly asks for a forward-looking change.