Redis XADD broken pipe interrupts Chatflow finalization and loses persisted answer

**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 bug report, 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.

### Dify version

1.13.3 (Enterprise 3.9.10)

### Cloud or Self Hosted

Self Hosted (Docker), deployed to Kubernetes with Enterprise Helm.

### Steps to reproduce

1. Create an Advanced Chat application whose Chatflow emits multiple streaming events and produces a non-empty final answer.
2. Send a streaming request so `workflow_based_app_execution_task` consumes the application response generator and publishes each response through the Redis Streams topic.
3. Interrupt the Redis connection while `StreamsTopic.publish()` executes `XADD` for an intermediate response event, while allowing the workflow execution thread to continue.
4. Restore Redis connectivity and inspect the workflow run, node outputs, and the associated conversation message.

A representative transport failure is:

```text
redis.exceptions.ConnectionError: Error 32 while writing to socket. Broken pipe.
```

The failure path is:

```text
workflow_based_app_execution_task
-> _publish_streaming_response
-> StreamsTopic.publish
-> Redis.xadd
```

### ✔️ Expected Behavior

A broken pipe during response delivery should not stop consumption of the application response generator. The worker should continue consuming through the terminal queue event so Advanced Chat finalization persists the complete `Message.answer` and related metadata.

After the response stream is drained, Dify may attempt a fallback terminal delivery and propagate or record the original broken-pipe error. Other delivery failures and generator iteration failures should retain their existing immediate propagation behavior.

### ❌ Actual Behavior

`_publish_streaming_response()` iterates the application response generator and synchronously calls `topic.publish()` in the same exception boundary. When Redis `XADD` raises, the helper immediately stops iterating the generator, attempts a synthetic failed terminal response, and re-raises the transport error.

The workflow execution thread can continue and persist a successful `WorkflowRun`, but the Advanced Chat response pipeline never consumes `QueueWorkflowSucceededEvent`. Consequently, `_handle_advanced_chat_message_end_event()` does not call `_save_message()`, leaving `Message.answer` empty even though the workflow and its final node completed with a non-empty output.