…-wait

Copilot review finding (low) on docker#14290: with --wait-timeout supplied but
not --wait, a dependency timeout in upDetached returned the raw "context
deadline exceeded" instead of the actionable "timeout waiting for
dependencies" the legacy start()+waitDependencies path already reports
for the exact same failure. The --wait-specific "application not healthy
after %s" translation only ever covered the Wait=true case, leaving the
Wait=false, WaitTimeout>0 case (a legal CLI combination -- --wait-timeout
alone is a hang guard) with no translation at all.

Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>

Copilot flagged a behavior-parity regression on docker#14290's Create->Start
barrier: a service's OpWaitCondition node only depended on its own
dependency's chain end, so its exec.waitTimeout clock could start
ticking earlier than the old imperative engine's single
waitDependencies(X) call. That call only begins once EVERY direct
dependency of X has itself finished starting (confirmed by reading
InDependencyOrder's graphTraversal.run: a service's visitorFn only
runs once none of its dependency children are still ServiceStopped).
A slow sibling with no wait node of its own (service_started is a
plain edge, nothing to poll) could silently eat into a health check's
effective grace period compared to the old engine.

startPhaseDependencies now computes allTargets, the union of every
declared dependency's own chain-end for the requesting service, and
passes that into waitConditionNode instead of just the one dependency
being checked.

Because wait nodes are shared/deduplicated across consuming services
by (dep, condition) alone, this widening reopened a second, more
serious finding from the same review pass: two consumers of the same
shared node can have different sibling sets, and merging a sibling
that already (transitively) depends on the shared node -- an entirely
ordinary diamond dependency, or a service whose own chain end
collapses onto the wait node itself when it has nothing left to start
-- creates a dependency cycle. The executor has no cycle detection and
no timeout on the dependency-wait phase itself (exec.waitTimeout only
applies once a node starts executing), so this was a guaranteed
permanent hang, not a correctness nicety.

Fixed with wouldCreateCycle: a wait node's merge now skips any
candidate that already (transitively) depends on it. This is provably
safe, not a workaround -- if a candidate already depends on the wait
node, the wait node is necessarily already done by the time the
candidate's own chain completes, so there is nothing to gain from also
adding the reverse edge; the candidate's own direct dependency on the
shared node (or on an intermediate sibling) already encodes everything
the consumer's depends_on requires.

Five new regression tests in reconcile_start_test.go, all verified by
ablation (reverting the relevant guard reliably reproduces the
original bug, 3-5/5 runs depending on the test):
- TestPlanStart_WaitNodeGatedOnAllSiblingDependencies: the original
  parity fix (db:service_healthy + migrate:service_started siblings).
- TestPlanStart_DiamondDependencyNeverCreatesWaitCycle and
  TestPlanStart_ExceptionalChainCollapseNeverCreatesWaitCycle: the two
  concrete cycle shapes found in review.
- TestPlanStart_TransitiveChainNeverCreatesWaitCycle: exercises
  wouldCreateCycle's BFS two hops deep, not just a direct edge.
- assertNoCycle, a plan-wide helper used by the cycle tests above.

Verified: go build, go test ./pkg/compose/..., and golangci-lint all
clean; full e2e suite re-run clean against a locally built binary
(same 3 pre-existing, environment-specific failures as the stack's
baseline: TestWatch, TestIPC, TestComposeModel). Two rounds of local
Copilot CLI review: the first caught the cycle risk in the initial
allTargets widening, the second confirmed wouldCreateCycle's BFS is
correct and complete, the "skipping is safe" reasoning holds in every
case, and no other call site in reconcile.go has the same unguarded
sharing risk.

Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>

Reverts 365f002, a behavior-parity fix for a Copilot finding that the
plan-based start engine's per-(dependency,condition) wait node could
start its exec.waitTimeout clock earlier than the old imperative
engine's single waitDependencies(X) call -- which only begins once
EVERY direct dependency of X has itself finished starting, so a slow
sibling with no wait node of its own could silently extend another
dependency's effective grace period.

On reflection that old-engine coupling is itself the bug: a service's
declared --wait-timeout for a given dependency should bound how long
THAT dependency takes to satisfy its condition, period -- not be
inflated by how long an unrelated sibling dependency happens to take
to start. Letting db's health-check timeout silently grow because
migrate's own dependency chain is slow means --wait-timeout no longer
means what it says. Restoring the narrower, per-dependency gating is a
deliberate, accepted behavior change from the old engine, not a parity
regression to chase.

This also removes the dependency-cycle risk the sibling-widening
introduced (an ordinary diamond dependency, or a service whose own
chain end collapses onto a shared wait node, could merge a node back
into its own transitive dependents -- see 365f002's description) and
the wouldCreateCycle machinery and five regression tests that existed
solely to guard against it, now dead weight with no reachable scenario
to protect against.

Verified: go build, go test ./pkg/compose/..., and golangci-lint all
clean.

Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>

The final readiness check opened its --wait-timeout window before
re-listing the project's containers, so a slow daemon listing could
exhaust the budget and report "application not healthy" before
waitDependencies had polled once. List first on the caller's context,
then derive the timed one, as the imperative path did.

Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>

…m DeadlineExceeded

up translated any DeadlineExceeded surfacing from the plan into "timeout
waiting for dependencies" or "application not healthy" whenever
--wait-timeout was set, even one coming from an engine call, a hook or
the secret injection, none of which is a dependency-readiness failure.

A wait node whose own --wait-timeout window expired now returns
errWaitTimeout (still satisfying DeadlineExceeded), and up keys its
message on that. A deadline inherited from the caller is never marked.

The test that checks --wait-timeout does not leak into non-wait nodes now
inspects the context those nodes receive, instead of a mock that would
have succeeded either way.

Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>

…th --wait too

Copilot review finding on docker#14296: a wait node's own timeout is a
depends_on condition that did not become satisfied during the plan, not
the final --wait readiness check, which runs after the plan and has its
own "application not healthy" translation. The imperative path reported
"timeout waiting for dependencies" for the former regardless of --wait,
but translateWaitTimeout rewrote it as "application not healthy" when
--wait was set. It now always reports the dependency timeout.

Also mark the test nodes that stand for the Start phase as PhaseStart
(the recreate-then-start plan and the wait whose timeout survives a
skipped dependent), so they exercise the Create->Start barrier the way
the reconciler's plans do instead of running everything in one phase.

Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>

Copilot review finding on docker#14296: planServiceStart returned before any
dependency planning for every service whose scale is zero. The imperative
startService only treats deploy.replicas: 0 as an unconditional no-op: a
service with scale: 0 still has its depends_on conditions evaluated first,
so an unhealthy or missing required dependency fails `up`/`start`, and
whatever is ordered after the service stays ordered after those
prerequisites. It is simply never an error for it to have no container to
start, and under scope Start the replicas it already owns are started
(CreateStart removes them all in the create phase).

Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>

Copilot review finding on docker#14300: if a sibling Create-phase failure ever
stopped canceling the other node, VolumeCreate's mock blocks on its ctx
while exec.run waits for it, so the test's own five-second guard could
never fire and the regression would hang until the suite-wide timeout.
Give run a deadline of its own and assert the cancellation is the
sibling's (context.Canceled), not that fallback.

Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>

…ency

The wiring of --wait-timeout into the plan's dependency waits was only
covered by executor tests that set the timeout by hand, and by an e2e
without depends_on. The scenario has a dependency that never gets
healthy and checks that up -d --wait-timeout fails with the dependency
timeout message (without the raw deadline error) and leaves the
dependent service created but not started.

Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>