Ctrl+C leaks function containers: no signal handling, so cleanup never runs on interrupt #515

What happened?

Interrupting a run with Ctrl+C leaks the function containers it started. Nothing in cmd/ handles signals: there is no signal.Notify or signal.NotifyContext anywhere. So SIGINT (and SIGTERM, e.g. a CI job being cancelled) terminates the process with Go's default behaviour, and no deferred function runs, including the processor Cleanup that removes the containers.

The code believes otherwise. The cleanup defers in cmd/diff/xr.go and cmd/diff/comp.go both justify using a detached context this way:

The command context may be cancelled (user Ctrl+C, timeout, etc.), which would cause Docker API calls to fail immediately, leaving containers running.

Ctrl+C never cancels that context. The run context comes from initializeAppContext (cmd/diff/cmd_utils.go), which is context.WithTimeout(context.Background(), timeout), so the only way it gets cancelled is --timeout expiring. The Ctrl+C case the comments describe is the one case that always leaks.

CachedFunctionProvider names its containers with a random per-process instanceID, so a later run never reuses or reclaims them. Each interrupted run leaves its containers behind until someone removes them by hand. That matters most in CI, where cancelled jobs are routine.

How can we reproduce it?

crossplane-diff comp updated-composition.yaml   # any run that starts function containers
# press Ctrl+C while it is rendering
docker ps --filter name=crossplane-diff          # the run's containers are still running

How could crossplane-diff help solve your problem?

Derive the run context from signal.NotifyContext(ctx, os.Interrupt, syscall.SIGTERM) in initializeAppContext, so an interrupt cancels the run instead of killing the process. The existing cleanup path then runs on interrupt. It already detaches from the run context's cancellation, and it will use context.WithoutCancel once the shared cleanup helper in #496 lands, which is exactly what an interrupted run needs: the work stops, and cleanup still finishes within its own timeout.

Things to decide and test:

• A second interrupt should force an exit. Otherwise a hung Docker daemon turns Ctrl+C into a 30-second wait (CleanupTimeout) with no way out. A common pattern: stop the signal handler after the first signal, so the next one uses Go's default and kills the process.
• Exit code: an interrupted run should exit non-zero and distinguishably, not report success or "diffs detected".
• Structured output: decide whether an interrupted -o json run still writes a document. The "always render" contract suggests it should, with an error saying the run was interrupted.

What environment did it happen in?

crossplane-diff main at 58d1ade. The behaviour is pre-existing. Found while reviewing the cleanup changes in #496.