AddPostgres: GSSAPI security context warnings spam console logs on Windows

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Describe the bug

When running an Aspire AppHost with `AddPostgres()` on Windows, every Npgsql connection from the .NET API project to the Linux PostgreSQL container produces repeated `could not accept GSSAPI security context` warnings in the Aspire Dashboard console logs.

These warnings are **harmless** — Npgsql falls back to password/SCRAM-SHA-256 authentication successfully — but they **clutter the console output significantly**, making it harder to spot real issues during development.

The root cause is that the PostgreSQL Linux container doesn't support GSSAPI (Kerberos) authentication, but Npgsql on Windows attempts GSSAPI negotiation first before falling back. Each connection attempt produces one or more warning lines in the container's stderr, which Aspire surfaces in the dashboard console logs.

### Expected Behavior

GSSAPI warnings should be suppressed, filtered, or downgraded in the Aspire Dashboard console logs for the PostgreSQL container, since GSSAPI negotiation failure is **expected** on Windows-to-Linux-container connections and Npgsql falls back gracefully to password auth.

Alternatively, the PostgreSQL container configuration could disable GSSAPI negotiation proactively (e.g., via `pg_hba.conf` settings that skip GSS auth methods).

### Steps To Reproduce

1. Create a new Aspire AppHost (single-file `.cs` format works):

```csharp
#:sdk Microsoft.NET.Sdk
#:sdk Aspire.AppHost.Sdk@13.2.0-preview.1.26110.1
#:package Aspire.Hosting.AppHost@13.2.0-preview.1.26110.1
#:package Aspire.Hosting.PostgreSQL@13.2.0-preview.1.26110.1

var builder = DistributedApplication.CreateBuilder(args);

var postgres = builder.AddPostgres("postgres")
.AddDatabase("mydb");

var api = builder.AddProject("api", "./src/api")
.WithReference(postgres);

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

2. In the API project, register Npgsql and make any EF Core query:

```csharp
builder.AddNpgsqlDbContext("mydb");
```

3. Run `aspire run` on **Windows** (tested on Windows 11)

4. Open the Aspire Dashboard → navigate to **Console Logs** for the `postgres` container

5. Observe repeated `could not accept GSSAPI security context` warnings for every connection attempt. The warnings appear on each new connection and significantly clutter the log output.

### Exceptions (if any)

No exceptions — GSSAPI warnings are logged by the PostgreSQL container (not the .NET process). Example log lines from the `postgres` container console:

```
LOG: could not accept GSSAPI security context
DETAIL: ...
```

The .NET API connects successfully via SCRAM-SHA-256 fallback. No application-level errors occur.

### .NET Version info

```
.NET SDK:
Version: 10.0.102
Commit: 4452502459
Workload version: 10.0.100-manifests.73000c7b
MSBuild version: 18.0.7+445250245

Runtime Environment:
OS Name: Windows
OS Version: 10.0.26220
OS Platform: Windows
RID: win-x64
```

### Anything else?

**Aspire package versions:**
- `Aspire.AppHost.Sdk`: 13.2.0-preview.1.26110.1
- `Aspire.Hosting.AppHost`: 13.2.0-preview.1.26110.1
- `Aspire.Hosting.PostgreSQL`: 13.2.0-preview.1.26110.1
- `Aspire.Npgsql.EntityFrameworkCore.PostgreSQL`: 9.4.0-preview.1.25265.8

**IDE:** Aspire CLI (`aspire run`)

**Additional context:**
- Docker Desktop with Linux containers
- PostgreSQL image: `postgres:17.6`
- This affects developer experience significantly on Windows — the GSSAPI warnings are the **majority** of console log output for the postgres container, drowning out useful startup and query information.
- The issue is cosmetic/DX — no functional impact. But Aspire's value proposition is a great inner-loop experience, and noisy console logs undermine that.

Start by reproducing the Windows-to-Linux-container scenario from the AddPostgres setup and inspect the PostgreSQL container's Console Logs in the Aspire Dashboard. Compare the reported GSSAPI warnings with the pg_hba.conf configuration and determine whether the fix belongs in container configuration or log handling. Done means expected GSSAPI failures no longer spam the dashboard while password/SCRAM authentication continues to work.

Written by the indexing model from the issue text.