Keycloak Startup time regression

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Describe the bug

In previous releases there was startup time regression in keycloak and was attributed to issues in other areas.
Those issues are reported to have been fixed, and yet we still see 3+ minutes startup time for Keycloak.

This slowdown is hurting our e2e tests in CI. We prepull the image before `aspire start` so the only cost is the actual container startup time.

I tried to reproduce it with a minimal apphost, and it only took 23 seconds, so probably something about the orchestration of our apphost is making the keycloak startup slow.
In local development I can see that it takes a while before aspire tries to start the docker, and even after it is started it takes a long time.

### Expected Behavior

starting keycloak takes 23 seconds in an empty apphost - the startup time in a larger apphost shouldn't be substantially longer (less than 1 minute).

### Steps To Reproduce

I created an empty apphost with only keycloak and it started up in 23 seconds.
In our large apphost it took over 3 minutes in CI, and locally 2 minutes.

### Exceptions (if any)

_No response_

### Aspire doctor output

```plain
➜ aspire doctor

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

Aspire
✅ Aspire CLI version 13.5.3 (channel: stable)
✅ Developer Control Plane (DCP) connection health checks succeeded

AppHost
✅ AppHost version 13.5.3 (apphost.cs)

.NET SDK
✅ .NET 10.0.203 installed (arm64)

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

Environment
✅ Operating system: macOS 15.7.7
✅ HTTPS development certificate is trusted

Development Tools
✅ Aspire extension for VS Code is installed

Summary: 8 passed, 0 warnings, 0 failed

Aspire CLI Installations
========================

╭───────────────────────────────────────────┬─────────────────────────────────────────────────┬─────────┬───────────┬─────────────╮
│ Path │ Version │ Channel │ Route │ PATH status │
├───────────────────────────────────────────┼─────────────────────────────────────────────────┼─────────┼───────────┼─────────────┤
│ /Users/twald/.aspire/bin/aspire (current) │ 13.5.3+b5f143315ffb6968ea939a9978797a5b20e4c688 │ stable │ (unknown) │ active │
╰───────────────────────────────────────────┴─────────────────────────────────────────────────┴─────────┴───────────┴─────────────╯
```

### Anything else?

_No response_

Start by comparing startup timing and logs between the minimal AppHost and the large AppHost, focusing on the delay before Docker starts and the time after container startup. Reproduce locally and in CI, then identify the orchestration step responsible and verify that the large AppHost starts Keycloak in under one minute.

Written by the indexing model from the issue text.