fix(mcp): apps.create reports started=true on partial sidecar failure

Coolify's `compose up -d` returns non-zero whenever any sidecar container
hits a `depends_on: condition: service_healthy` timeout. For slow-booting
apps like Twenty (where the worker waits ~3 min for twenty's healthcheck),
this caused apps.create to return `started: false` even when the primary
stack was running fine.

Now ensureServiceUp probes the host with `docker ps` after a non-zero
compose exit and returns started=true whenever any container is running,
surfacing the compose stderr in startDiag so agents can decide whether
to retry apps.containers.up later. Bumps MCP to v2.4.2 and updates
AI_CAPABILITIES.md changelog.

Made-with: Cursor

AI_CAPABILITIES.md

@@ -587,7 +587,7 @@ The MCP descriptor at `GET /api/mcp` reports a semver `version`. Tool names
 are append-only within a major version — agents can cache the tool list
 safely for the duration of a conversation but should re-fetch on 404.
 
-Current version: **2.4.1**.
+Current version: **2.4.2**.
 
 - **1.x** — session-cookie-only MCP, no tenant keys.
 - **2.0** — `vibn_sk_…` keys, workspace-scoped Gitea bot + Coolify project.
@@ -607,6 +607,14 @@ Current version: **2.4.1**.
   pathways) now auto-falls-back to direct `docker compose up -d` over SSH
   when Coolify's queue stalls, so a single `apps.create` call really does
   leave a running stack.
+- **2.4.2** — `apps.create` no longer reports `started: false` when only a
+  sidecar (worker / scheduler) failed its `depends_on: service_healthy`
+  gate. We now probe the host with `docker ps` after `compose up -d` and
+  return `started: true` whenever any container of the stack is running,
+  surfacing the compose stderr in `startDiag` so agents can decide whether
+  to re-run `apps.containers.up` later. This matches the real-world
+  behavior of slow-booting apps like Twenty (worker waits ~3 min for
+  twenty's healthcheck, exceeds compose's default depends_on timeout).
 
 ---