Kubernetes publisher emits an HTTPS service reference for a port not exposed by the generated Service

### Describe the bug

When a project has its HTTP endpoint published on a different Kubernetes service port than its container target port, the Kubernetes publisher emits a valid HTTP service reference and an invalid HTTPS service reference.

For an HTTP endpoint with service port `8081` and target port `8080`, the generated artifacts contain:

```yaml
APISERVICE_HTTP: "http://apiservice-service:8081"
services__apiservice__http__0: "http://apiservice-service:8081"
APISERVICE_HTTPS: "https://apiservice-service:8080"
```

However, the generated Kubernetes Service exposes only port `8081`:

```yaml
ports:
- name: "http"
protocol: "TCP"
port: 8081
targetPort: 8080
```

There is no service port `8080`, and the workload listens for HTTP rather than HTTPS on container port `8080`. The generated HTTPS reference is therefore unreachable.

### Expected Behavior

Generated service-discovery references should only describe endpoints reachable through the generated Kubernetes Service. In this case, the publisher should emit the HTTP reference on port `8081` and omit the invalid HTTPS reference.

### Steps To Reproduce

1. Create a C# Aspire starter application and add the Azure Kubernetes hosting integration.
2. Configure its AppHost as follows:

```csharp
using Aspire.Hosting.Azure.Kubernetes;

var builder = DistributedApplication.CreateBuilder(args);

var environment = builder.AddAzureKubernetesEnvironment("aks");

var api = builder.AddProject("apiservice")
.WithEndpoint("http", endpoint =>
{
endpoint.Port = 8081;
endpoint.TargetPort = 8080;
})
.WithComputeEnvironment(environment);

builder.AddProject("webfrontend")
.WithReference(api)
.WithComputeEnvironment(environment);

builder.Build().Run();
```

3. Generate the Helm chart without deploying:

```bash
aspire publish --output-path ./artifacts
```

4. Compare these generated files:

```text
artifacts/templates/apiservice/service.yaml
artifacts/values.yaml
```

`service.yaml` exposes `8081 -> 8080`, while `values.yaml` configures the consuming project with `https://apiservice-service:8080` even though no Kubernetes service port `8080` exists.

### Exceptions (if any)

None. Publishing succeeds, but the generated HTTPS service-discovery endpoint cannot be reached.

### Aspire doctor output

Reproduced with:

```text
Aspire CLI 13.5.0+0028557bee5d68bf5093b9a58501d714701c0da6
.NET SDK 10.0.302
```

### Anything else?

Relevant documentation:

- [Deploy to Kubernetes](https://aspire.dev/deployment/kubernetes/) documents that Aspire endpoints become Kubernetes Services.
- [Deploy to an existing Kubernetes cluster](https://aspire.dev/deployment/kubernetes/clusters/) states that generated Helm charts configure service references automatically using Kubernetes-native DNS.
- [Service discovery](https://aspire.dev/fundamentals/service-discovery/) documents that `WithReference` injects endpoint configuration containing the service's actual address.
- [Networking overview](https://aspire.dev/fundamentals/networking-overview/) distinguishes the service/host port from the target port on which the workload listens.

A live AKS deployment confirmed that `apiservice-service` exposed only `8081/TCP` targeting container port `8080`; the HTTP reference was reachable and the generated HTTPS reference was not represented by any Service port.

The Kubernetes and service-discovery behavior above was also verified against the Aspire docs `release/13.5` sources: [kubernetes.mdx](https://github.com/microsoft/aspire.dev/blob/75b6e80016007c6f286808dca390b0abd04f9b05/src/frontend/src/content/docs/deployment/kubernetes.mdx), [clusters.mdx](https://github.com/microsoft/aspire.dev/blob/75b6e80016007c6f286808dca390b0abd04f9b05/src/frontend/src/content/docs/deployment/kubernetes/clusters.mdx), and [service-discovery.mdx](https://github.com/microsoft/aspire.dev/blob/75b6e80016007c6f286808dca390b0abd04f9b05/src/frontend/src/content/docs/fundamentals/service-discovery.mdx).

Run the reported C# AppHost configuration with `aspire publish --output-path ./artifacts`, then compare `artifacts/templates/apiservice/service.yaml` and `artifacts/values.yaml`. Trace how the generated Service port and HTTP/HTTPS service-discovery references are produced; done means the references describe only reachable Kubernetes Service ports, with the invalid HTTPS reference omitted in this case.

Written by the indexing model from the issue text.