Something not right in the end node of the workflow

### 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.16.0

### Cloud or Self Hosted

Self Hosted (Docker)

### Steps to reproduce

As the title suggests, the end node in the workflow has a design that feels very inconvenient to use. That is, the output field names of different end nodes must be different.
However, in the workflow, there is a very common situation where different branches need to output the same fields. When calling this workflow in a chatflow, use the same field parsing to obtain the content output by different branches. If following the current rules, then a large number of different parsing rules need to be set to cope with the different output field names of different end nodes. As shown in the following figure, this is a workflow I built a long time ago. At that time, there was no error alert, but now there are numerous errors related to the same-named fields：

### ✔️ Expected Behavior

Different end node can set fields with different name.

### ❌ Actual Behavior

Different end node can`t set fields with different name.

The report names no files or tests. Start by reproducing the workflow with multiple end nodes and inspect how their output fields are validated and consumed by a chatflow; confirm whether matching field names across branches are intended. Done means the branches can expose the shared fields and chatflow parsing works without the reported errors.

Written by the indexing model from the issue text.