`aspire describe`/dashboard report a stale endpoint URL for `.WithHttpsEndpoint()` project resources — actual Kestrel bind port differs every run

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Describe the bug

# `aspire describe`/dashboard report a stale endpoint URL for `.WithHttpsEndpoint()` project resources — actual Kestrel bind port differs every run

## Environment

| | |
|---|---|
| Aspire CLI | `13.6.0-preview.1.26418.4+95ba0548da04adf7d7fe6866fff9e3df2d2ee549` (daily channel) |
| AppHost SDK | `Aspire.AppHost.Sdk/13.6.0-preview.1.26416.2` |
| Hosting packages | `Aspire.Hosting.{Nats,PostgreSQL,Redis,Python}` @ `13.6.0-preview.1.26416.2` |
| .NET SDK | `10.0.400` (x64) |
| OS | Windows 10.0.26200.0 (Windows 11 Pro) |
| Container runtime | Docker v29.7.2, running |
| `aspire doctor` | 8/8 checks pass, 0 warnings, 0 failures |

## Summary

For every .NET project resource added via `builder.AddProject(name).WithHttpsEndpoint()` (no explicit port pinned), `aspire describe --format Json` and the dashboard report an endpoint URL the process is **not actually listening on**. The real Kestrel bind port — visible in the process's own stdout — is a different, freshly OS-assigned ephemeral port each run. Any other resource that calls the reported endpoint, including Aspire's own service-discovery-injected env vars, gets connection failures, since nothing is listening there.

### Expected Behavior

`aspire describe`'s reported `urls[].url` for each project resource matches the port Kestrel is actually bound to (i.e. what appears in that resource's own log as `Now listening on: ...`), and stays consistent with whatever DCP actually injects via `ASPNETCORE_URLS` / service-discovery env vars for other resources to call.

### Steps To Reproduce

## Repro steps

1. AppHost composes 10 C# project resources, each declared the same way, e.g.:

```csharp
builder.AddProject("svc-ledger")
.WithHttpsEndpoint()
// ...WithReference/WaitFor/WithEnvironment...
```

2. Each project has a `Properties/launchSettings.json` with a fixed `applicationUrl`, e.g. (`Sente.PiiProxy`):

```json
{
"profiles": {
"Sente.PiiProxy": {
"commandName": "Project",
"launchBrowser": true,
"environmentVariables": { "ASPNETCORE_ENVIRONMENT": "Development" },
"applicationUrl": "https://localhost:55182;http://localhost:55190"
}
}
}
```

3. DCP launches the process explicitly with `--no-launch-profile`:

```
Starting process...: Cmd = C:\Program Files\dotnet\dotnet.exe, Args = [
"run", "--project", "...\Work.PiiProxy.csproj",
"--no-build", "--configuration", "Debug", "--no-launch-profile"
]
```

4. Run `aspire start --non-interactive`, then `aspire describe --format Json`.

### Exceptions (if any)

`aspire describe` reports the **same static ports** every run, matching each project's `launchSettings.json` `applicationUrl`, while the process's own log shows it bound to a **different, randomly-assigned port** that changes on every `aspire start`. Reproduced identically across two independent clean `aspire stop` → `aspire start` cycles.

| Resource | `aspire describe` reports | Actual Kestrel bind (process stdout) | Reachable at reported URL? |
|---|---|---|---|
| `svc-pii-proxy` | `https://localhost:55182`, `http://localhost:55190` | `https://localhost:62538`, `http://localhost:62539` | No — `curl` times out, `netstat` shows nothing listening on 55182/55190 |
| `svc-identity` | `https://localhost:55180`, `http://localhost:55184` | (never confirmed listening — blocked upstream, see below) | No |
| `svc-ledger` | `https://localhost:55187`, `http://localhost:55191` | `https://localhost:62540`, `http://localhost:62541` | No |
| `svc-settlement`, `svc-transfers` | Also static `551xx` ports, same pattern | Not individually verified but the same launchSettings-fixed-port pattern is present in every service | Presumed same bug |

All affected resources are reported `state: "Running"`, `healthStatus: "Healthy"` in `aspire describe` despite being unreachable at the reported address — health checks appear to validate the internal/actual port while the *displayed* endpoint URL is wrong.

### Aspire doctor output

Checking Aspire environment...

Aspire Environment Check
========================

Aspire
✅ Aspire CLI version 13.6.0-preview.1.26418.4 (channel: daily)
✅ Developer Control Plane (DCP) connection health checks succeeded

AppHost
✅ AppHost version 13.6.0-preview.1.26416.2 (Sente.AppHost.csproj)

.NET SDK
✅ .NET 10.0.400 installed (x64)

Container Runtime
✅ Docker v29.7.2: running (auto-detected (default)) ← active

Environment
✅ Operating system: Windows 10.0.26200.0
✅ HTTPS development certificate is trusted

Development Tools
✅ Aspire extension for VS Code is installed

Summary: 8 passed, 0 warnings, 0 failed

Aspire CLI Installations
========================
C:\Users\malis\.aspire\bin\aspire.exe (current) │ 13.6.0-preview.1.26418.4+95ba0548da04adf7d7fe6866fff9e3df2d2ee549 │ daily │ (unknown) │ active

Clean bill of health across the board — which is exactly why the endpoint-mismatch is worth reporting as a DCP bug rather than an environment problem: nothing here flags SDK/cert/Docker/CLI issues, yet 3+ project resources are unreachable at the ports aspire describe reports.

### Anything else?

## Additional notes

- This is **not** an application misconfiguration. Our shared Kestrel setup helper (`ConfigureGrpcKestrel()`) only sets `HttpProtocols.Http1AndHttp2` on `ConfigureEndpointDefaults`; it does not touch bind addresses or ports.
- `aspire doctor` reports a fully healthy environment (CLI, DCP connection, AppHost, .NET SDK, Docker, dev cert trust), ruling out a basic environment problem.
- Every affected project uses the identical `.WithHttpsEndpoint()` (no explicit port) pattern. Services that don't go through this path — Python services launched via `uvicorn --port` reading an Aspire-set env var, and Next.js/Astro apps launched via a custom `AddNpmDevApp` reading `PORT` — were **not** observed to have this problem; their reported URLs matched reality in the same run (the gateway's health endpoint and the merchant web app both returned `200` at their reported ports). This narrows the bug to the `AddProject().WithHttpsEndpoint()` path specifically, likely interacting with the presence of a `launchSettings.json` `applicationUrl` alongside DCP's `--no-launch-profile` launch flag.

## Suggested area to check

A possible mismatch between the endpoint URL DCP *computes for display* — which appears to fall back to `launchSettings.json`'s `applicationUrl` when `.WithHttpsEndpoint()` has no explicit port — versus the endpoint URL DCP actually *assigns and injects* into the process's `ASPNETCORE_URLS` (which the process correctly binds to, but which the CLI's `describe`/dashboard output never reflects)