[Refactor/Chore] Decouple execution lifecycle from generator and iterator lifecycle

**AI disclosure**: This issue was drafted and analyzed with Codex. I have reviewed the analysis, and I am responsible for the content.

### Self Checks

- [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542).
- [x] This is only for refactors or chores; if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general).
- [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones.
- [x] I confirm that I am using English to submit this report, otherwise it will be closed.
- [x] 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
- [x] Please do not modify this template :) and fill in all the required fields.

### Description

Dify workflow execution currently spans a nested chain of generators and iterators. At different points in the chain, iteration is responsible for driving GraphEngine events, filtering and translating events, publishing them to an app queue, consuming that queue, constructing application responses, and relaying serialized responses to downstream subscribers.

This makes two conceptually independent lifecycles share the same Python control-flow mechanics:

1. **Execution lifecycle**: starting and stopping the graph dispatcher and workers, processing cancellation, recording workflow and node state, and reaching a workflow outcome.
2. **Generator/iterator lifecycle**: advancing an iterator, suspending at a yield point, exhausting it, closing it, unwinding the owning frame, or releasing the last reference to it.

The relationship is implicit rather than represented by an execution-level contract.

When a generator is suspended after yielding an event, an exception raised by the caller while handling that event occurs outside the generator. The exception is not necessarily observed as an execution failure inside the generator. If the caller frame unwinds and releases the generator, generator finalization can inject `GeneratorExit` through the nested generator chain and execute GraphEngine cleanup. This may stop execution subsystems without following the same terminal-event path as an ordinary workflow failure, abort, pause, or success.

The reverse dependency also exists. Outer layers use iterator exhaustion, terminal events observed during iteration, and generator cleanup to infer whether execution completed, whether a listener segment ended normally, whether a worker thread should be joined, and whether a fallback terminal response is required. Workflow failures can therefore appear at different layers as Python exceptions, graph terminal events, app queue events, or stream responses.

This coupling is visible across the following areas:

- `graphon.GraphEngine.run()`
- `api/core/workflow/workflow_entry.py`
- `api/core/app/apps/workflow/app_runner.py`
- `api/core/app/apps/base_app_generator.py`
- `api/core/app/apps/base_app_queue_manager.py`
- `api/core/app/apps/workflow/generate_task_pipeline.py`
- `api/tasks/app_generate/workflow_execute_task.py`

The problem is not that generators are used for streaming. The problem is that the lifetime of generator and iterator objects participates in owning and determining the lifetime of a concurrent workflow execution.

This is distinct from the response-listener boundary addressed by #39782 and #39813. Those changes separate HTTP or response-listener detachment from execution cancellation. The deeper execution path still relies on generator ownership, iteration progress, exception propagation, and finalization to connect the engine, worker thread, event pipeline, and terminal outcome.

### Motivation

The current lifecycle relationship creates several forms of architectural risk:

- **Implicit ownership**: it is difficult to identify which component owns execution completion and cleanup without following the complete generator chain.
- **Partial termination**: generator cleanup can stop scheduling and event processing while in-flight node work or external side effects continue.
- **Ambiguous terminality**: iterator exhaustion, stream termination, worker completion, graph terminal events, persisted workflow status, and Celery task status can diverge.
- **Error translation across layers**: one failure can be converted between exceptions and multiple event representations, making duplicate, missing, or conflicting terminal signals possible.
- **Change amplification**: changes to pause, resume, cancellation, reconnect, timeout, or streaming behavior require reasoning across engine, queue, persistence, response, and worker-thread boundaries.
- **Runtime-specific reasoning**: correctness can depend on CPython generator finalization, traceback reference lifetime, `GeneratorExit`, and `yield from` propagation.
- **Test fragility**: tests must reproduce object ownership and cleanup timing in addition to the intended workflow state transition.

These risks become more significant as workflow execution gains longer-lived runs, pause and resume segments, distributed control commands, reconnectable event streams, and additional execution backends.

### Additional Context

Related reports and changes:

- #39782 identifies the conflation of response-listener completion and app execution terminal state.
- #39813 decouples response-listener detachment from execution cancellation.
- #20237 explicitly reports `GeneratorExit` interrupting workflow status updates after client disconnect.
- #12798, #23654, and #26169 report workflow executions remaining in `running` after the client or streaming connection disappears.
- #37129 prevents a legacy stop check from interrupting GraphEngine before it emits a terminal event.
- #37919 adds defensive terminal-event handling around broken workflow streams.
- #39614 ties response-stream cleanup to waiting for the workflow producer thread.
- langgenius/graphon#244 discusses GraphEngine event identity and buffering, but explicitly excludes cancellation, persistence, asynchronous task abstractions, and a new event bus.

This issue intentionally records only the remaining lifecycle boundary and its consequences. It does not prescribe a replacement abstraction, concurrency model, event transport, persistence design, or migration plan.

Start by tracing graphon.GraphEngine.run() through api/core/workflow/workflow_entry.py, api/core/app/apps/workflow/app_runner.py, api/core/app/apps/base_app_generator.py, api/core/app/apps/base_app_queue_manager.py, api/core/app/apps/workflow/generate_task_pipeline.py, and api/tasks/app_generate/workflow_execute_task.py. Review the related issues and existing lifecycle tests first; this issue does not define a replacement abstraction, migration plan, or concrete completion criteria.

Written by the indexing model from the issue text.