Adjust timeout to ignore pull activity

[adrum]

I noticed some bigger images on slower networks could exceed the 30s timeout. This modifies container-compose up -d to consider pull activity progress to determine if the command is dormant or not.

[Cyb3rDudu]

The idle-timeout approach is the right call, and the doc comment is ok. A few things before I'll merge:

1. Dropping the deadline for while true also drops the old hard ceiling. In -d mode it's fine, but a container that keeps spitting logs every few seconds without ever reaching running would now hang up -d forever instead of failing at 30s. I'd keep an absolute backstop (a few minutes) on top of the idle timeout.
2. When the idle timeout does fire, the container run task/process isn't cancelled or stopped - it just leaks in the background while up moves on to the next service. Cancel the task and stop the container in that error path.
3. Mind adding a test for the new ActivityClock? It's private right now, so it'd need to be internal or extracted into its own file,but it's the one piece that's cleanly unit-testable, the rest of the wait logic needs the real container runtime. A small test covering touch() / lastActivity under concurrent access would cover the new behavior; if you inject the
   clock instead of calling Date() directly you can even test the idle-window logic without leaning on Task.sleep.

[adrum]

@Cyb3rDudu Great feedback! I have addressed all three. I set the ceiling to 5 minutes, as I felt 3 would be on the edge of too short.