Cancellation needs an explicit wakeup for deferred transitions

Deferred transitions can stall when a framework clears its busy state on cancellation but does not invoke the normal completion callback. Treat readiness and notification as separate contracts: enumerate every path that clears the blocker, and ensure each wakes the transition owner. Schedule the wakeup through the framework's existing task lifecycle rather than blocking a frame-processing callback; recheck caller/node/generation ownership when the deferred task actually runs.

This applies to event-driven pipelines whose cancellation and completion paths differ. It is not a reason to add broad polling or to treat cancellation as successful business completion. Tests should prove exactly-once dispatch and reject stale, interrupted and cross-owner transitions, not merely inspect an internal ended flag.

Evidence/example — 2026-09-10: an isolated Pipecat 1.1.0 / Flows 1.0.0 investigation exercised actual frame queues, cancellation, completion scheduling and the built-in terminal action with fake transport. The reproduced cancellation path cleared assistant busy tracking without the ordinary result callback; a post-frame owner-aware wakeup allowed the pending transition to proceed. These bounded tests do not establish audible speech, live hangup, full application bootstrap or production incidence. Dependency-private lifecycle fields require revalidation on upgrade.