Balancing Linux distro CI coverage with container version vs latest

I have found myself updating CI coverage in `release/10.0` to Ubuntu 26.04 and `release/9.0-staging` and `release/8.0-staging` to Debian 13. This raises significant tension. This is new since we haven't previously been as aggressive about coverage.

Core tensions:

- We want bleeding-edge coverage to ensure users have a good experience on new distros versions.
- We want to have _very high_ confidence that users have a good experience using our `8.0`, `9.0`, and `10.0` container images. These are fixed for the lifetime of the release on a specific distro version.
- We want to keep our CI costs at a minimum (with some definition of "minimum").

Context:

- `8.0` and `9.0` tag images are based on Debian 12 (Bookworm) and will never upgrade to Debian 13 (Trixie).
- `10.0` tag images are based on Ubuntu 24.04 (Noble) and will never upgrade to Ubuntu 26.04 (Resolute).
- `11.0` targ images will be based on Ubuntu 26.04 (Resolute) ...

The simpler answer is to test both old and new. If everyone is good with that, this is simple.

IMO, it is a priority inversion to chase the future when we're clearly needing to satisfy a cloud-native reliability contract with these container images. That statement only applies if we for some reason conclude that we can only support one Debian version (for 8.0 and 9.0 branches) and one Ubuntu version (for 10.0 branches). This is similar to how we test two Azure Linux versions in our branches.

The proposal is that we test multiple versions in CI for this case.

Related:

- https://github.com/dotnet/runtime/pull/122326#issuecomment-3630416134
- https://github.com/dotnet/runtime/pull/122130