Handle destroy events in up monitor

[ousamabenyounes]

What I did
Handle container destroy events in the attached up monitor so docker compose up can finish when an externally stopped project removes a container that never emitted a die event.

The monitor still uses die for exit status and restart detection; destroy only removes the container from the tracked set so the monitor can terminate when the project is gone.

Related issue
Fixes #13985

Test verification (RED -> GREEN)

RED on origin/main with the new regression test only:

=== RUN   TestMonitorStopsAfterDestroyWithoutDie
    monitor_test.go:73: monitor did not stop after all containers were destroyed
--- FAIL: TestMonitorStopsAfterDestroyWithoutDie (1.00s)
FAIL
FAIL	github.com/docker/compose/v5/pkg/compose	1.026s

GREEN on this branch:

=== RUN   TestMonitorStopsAfterDestroyWithoutDie
--- PASS: TestMonitorStopsAfterDestroyWithoutDie (0.00s)
PASS
ok  	github.com/docker/compose/v5/pkg/compose	0.023s

Full local validation:

./run-ci.sh
DONE 574 tests, 2 skipped
make lint: golangci-lint run --build-tags "e2e" ./... -> 0 issues

[ndeloof]

Thanks a lot for digging into #13985 and for the clean regression test! Closing this one in favor of #13990 though — here is why.

Handling only destroy fixes the literal repro from the issue (stop then down), but not the underlying contract: an attached up must exit once all containers are stopped, not only once they are removed. I verified with the pre-regression v2.39.2 binary that an external docker compose stop alone (no down) makes the attached up exit within about a second. With the destroy-only approach, a container in restart backoff that is externally stopped emits only a stop event — no die, no destroy — so it never leaves the tracked set and up still hangs forever. I confirmed this empirically: the stop-alone e2e test in #14023 fails on this branch, and passes with #13990.

Unfortunately covering stop can't be a simple containers.Remove(...) either: during watch sync+restart (#13161) the engine emits stop then start on ContainerRestart, so a stop event has to be inspected to distinguish a transient stop from a terminal one — which is exactly what #13990 does. Its destroy handling matches yours, by the way.

Thanks again for the contribution!