Give the reports server health probes on Kubernetes once Aspire writes a valid probe scheme #147

AddReportsServer gives the server a readiness probe (/health/ready) and a liveness probe (/health/live) on every deployment target that runs probes, except Kubernetes. This issue tracks turning them on for Kubernetes once Aspire fixes its probe output.

Why Kubernetes is left out

Aspire's Kubernetes publisher writes the probe's scheme in lower case (scheme: "http"), but Kubernetes only accepts HTTP or HTTPS: microsoft/aspire#18271. The failure is silent. The StatefulSet is accepted, but its controller never creates the pod:

FailedCreate … spec.containers[0].livenessProbe.httpGet.scheme: Unsupported value: "http": supported values: "HTTP", "HTTPS"

Verified with aspire publish on Aspire 13.0 and 13.6, and on a k3s v1.33 cluster. Azure Kubernetes Service (AddAzureKubernetesEnvironment) uses the same publisher.

So AddReportsServer removes its probes on BeforeStartEvent when the model has a KubernetesEnvironmentResource or an AzureKubernetesEnvironmentResource (KubernetesEnvironmentTypes in ReportsServerBuilderExtensions.cs). Probes the AppHost adds itself stay.

When Aspire ships the fix

• Note the first Aspire.Hosting.Kubernetes (and Aspire.Hosting.Azure.Kubernetes) release with the fix.
• Keep the probes when the Kubernetes environment's assembly is at least that version. Raising the package's Aspire.Hosting floor isn't enough on its own, since the AppHost picks the Kubernetes package's version. Alternatively, drop the skip entirely once that release is old enough.
• Update the tests in HealthProbeTests (Leaves_the_probes_out_on_Kubernetes) and the test project's Aspire.Hosting.Kubernetes version.
• Remove the Kubernetes workaround from docs/aspire.md (Deploy → Health probes) and the remarks on AddReportsServer.
• Verify with aspire publish to Kubernetes and a real cluster: both probes are present, the scheme is HTTP, and the pod starts.