Using Aspire to programmatically assert OTLP telemetry is being emitted?

There's recently been some issues reported around the .NET OpenTelemetry OTLP exporter after some changes made the the underlying protobuf contracts that have surfaced what turns out to be a latent bug in the code in the SDK that exports metrics:

- https://github.com/open-telemetry/opentelemetry-collector/issues/13727
- https://github.com/open-telemetry/opentelemetry-dotnet/issues/6464
- https://github.com/open-telemetry/opentelemetry-dotnet/issues/6538

In the context of this issue, we've created an issue to track implementing a set of tests to help verify that the OTLP signals are interop correctly with ingestion servers such as the [OpenTelemetry Collector](https://github.com/open-telemetry/opentelemetry-collector): https://github.com/open-telemetry/opentelemetry-dotnet/issues/6463

I'm looking into doing this work at the moment, and researching what an appropriate approach for these tests might be. One possibility to implement these tests is using [OATs](https://github.com/grafana/oats), which is how the issue was first detected, which was created at Grafana.

Another thought I had, that might be easier to work with long-term for the .NET OpenTelemetry libraries specifically as it's a native .NET technology would be that maybe Aspire can help with this.

Aspire already ingests OTLP signals during local development, but as far as I'm aware it exposes to telemetry to the end user via the Aspire Dashboard, which is sourced from a "private" API. UI-based tests would likely be brittle and hard to maintain, so the desired implementation would be that ability to query the ingested telemetry to check what has been expected to be emitted by an application exists.

Is there a documented/supported/"public" way of querying Aspire to verify that specific OpenTelemetry telemetry signals have been received by its collector?

If not, is this something that could make sense to be added to Aspire in the future as part of a overarching testing/testability story?

I've used Aspire for integration an application itself, but not for the underlying telemetry itself, which seems like a different use case to the existing support for testing Aspire makes available with the Aspire.Hosting.Testing NuGet package.

Of course even if this were available/added, it might not have detected the specific compatibility issue here, but it would increase the test coverage for the OpenTelemetry .NET SDK regardless.