TestRunners.Common and TestRunners.Xunit packages have not published since 2023-09-09

## Summary

`Microsoft.DotNet.XHarness.TestRunners.Common` and `Microsoft.DotNet.XHarness.TestRunners.Xunit` have not been published to the `dotnet-eng` feed since **`1.0.0-prerelease.23252.4`** (2023-09-09), while `Microsoft.DotNet.XHarness.CLI` has continued publishing continuously and is currently at **`11.0.0-prerelease.26217.1`** (same feed).

This surfaced because #1565 (coverage collection) adds the CLI flag *and* the device-side `CoverageManager` that generates the Cobertura report. The CLI flag is reachable — consumers can install the new CLI — but the `CoverageManager` lives in `TestRunners.Common`, which hasn't been republished since 2023, so the end-to-end `--enable-coverage` flow cannot reach consumers.

## Evidence

Query the feed directly:

```
curl -s https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-eng/nuget/v3/flat2/microsoft.dotnet.xharness.testrunners.xunit/index.json
```

Last three `1.0.0-prerelease.*` versions are `23252.1`, `23252.4` (both 2023-09-09). No `11.0.0-*` versions exist.

Compare against CLI:

```
curl -s https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-eng/nuget/v3/flat2/microsoft.dotnet.xharness.cli/index.json
```

Has `11.0.0-prerelease.26217.1` (nuspec confirms `commit=866707736d49c2323628744716cda2475b3af9ee`, which is the #1565 merge commit).

Neither TestRunners package appears on nuget.org either (`BlobNotFound`).

## What I've been able to verify from the repo

- `eng/Versions.props` sets `11.0.0` globally — TestRunners inherit this, so a bump isn't the blocker.
- Both `Microsoft.DotNet.XHarness.TestRunners.Common.csproj` and `Microsoft.DotNet.XHarness.TestRunners.Xunit.csproj` have `true` already.
- `eng/Publishing.props` only disables symbol packages; no exclusion list.
- `azure-pipelines.yml` has `enablePublishBuildAssets: true` under the standard Arcade template. The only explicit pipeline-artifact path is `artifacts\bin\Microsoft.DotNet.XHarness.CLI` (L78), but that is separate from NuGet publish — Arcade's asset manifest is generated from all produced `.nupkg` files.
- I couldn't find any commit in `eng/` around 2023-09-09 that obviously toggled TestRunners off.

So from a static reading the packages *should* be publishing; something about the actual build or post-build step is filtering them out. I don't have access to a recent xharness pipeline build log to confirm whether the nupkgs are produced and then dropped at publish, or simply not produced.

## Questions

1. Is this a deliberate change — were the TestRunners packages retired in favour of a different distribution mechanism (source-shared, submodule, etc.) that I should be using instead?
2. If not deliberate: do you have visibility into whether the nupkgs are being produced (and, if so, what filters them out at publish time)?
3. If a PR would help, I've put up #XXXX (placeholder — will link once opened) as a minimal, conservative change that makes the shipping intent explicit and adds NuGet metadata. Happy to extend it once the root cause is clearer.

## Why it matters (consumer view)

On `feature/ON-10173` of a downstream MAUI Android device-test app (.NET 10, `net10.0-android36.1`), I've upgraded to `Microsoft.DotNet.XHarness.CLI 11.0.0-prerelease.26217.1` and confirmed the `--enable-coverage` flag is accepted and wired up through to the instrumentation run. Tests execute normally. But because the test app still links `Microsoft.DotNet.XHarness.TestRunners.Xunit 1.0.0-prerelease.23252.4`, no `INSTRUMENTATION_RESULT: coverage-results-path=` is emitted, xharness has nothing to pull via `adb`, and no Cobertura file is produced. Republishing TestRunners would make the PR-1565 feature actually usable end-to-end for consumers outside the dotnet repos.

Thanks for taking a look.

Start by inspecting eng/Versions.props, eng/Publishing.props, and azure-pipelines.yml, then query the dotnet-eng feed and obtain a recent pipeline build log if available. Determine whether the TestRunners nupkgs are produced and filtered during publishing; done means both packages publish a current version and the end-to-end coverage flow can consume them.

Written by the indexing model from the issue text.