Aspire takes a while to notice a container has failed to start

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Describe the bug

If a container fails to start, it can take aspire 10+ seconds to realise. Two such scenarios this can be reproduced in are:
- Point to an image that doesn't exist.
- `ImagePullPolicy.Never` with an image doesn't exist locally.

The logs immediately show the docker error failing to start the container, but the resource remains in the `Starting` state for about 10 seconds beyond that.

One other curiosity, when the container eventually reaches the FailedToStart` state, it is given a Start and Stop time. These match the time at which aspire realised the container failed to start, rather than the time I hit the "start" button on the dashboard.
1. How can the resource have a start time if it failed to start...
2. If it doe shave a start time, I'd expect it to match the time at which I hit the start button in the UI, not after the 10+ sec delay.

### Expected Behavior

Aspire should notice the container failed to start much sooner, and transition the resoruce to the `FailedToStart` state.

### Steps To Reproduce

Trying to use a container that doesn't exist
```
builder.AddContainer("fake", "does/not/exist/blah/blah");
```

### Exceptions (if any)

```
Executing command 'resource-start'.
Successfully executed command 'resource-start'.
Unable to find image 'does/not/exist/blah/blah:latest' locally
Error response from daemon: pull access denied for does/not/exist/blah/blah, repository does not exist or may require 'docker login'
```

### .NET Version info

_No response_

### Anything else?

_No response_