Dify API Returns HTTP 500 and Multi-Second Latency Under Bandwidth Degradation

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

### Cloud or Self Hosted

Self Hosted (Source)

### Steps to reproduce

1. Deploy Dify 1.17.0 on Kubernetes and verify that the Chatflow baseline request to `/v1/chat-messages` returns HTTP `200`.
2. Apply a Chaos Mesh `NetworkChaos` to one `dify-k8s-api` Pod with the following configuration:

- action: `bandwidth`
- mode: `one`
- rate: `1mbps`
- queue limit: `1000`
- buffer: `1000`
- duration: `30s`
- direction: `to`

3. Send the same Chatflow request while the bandwidth limit is active.
4. Record the HTTP status code and end-to-end latency.
5. Remove the bandwidth limit and verify that the Chatflow request recovers.

Environment:
- API image: `langgenius/dify-api:1.17.0`
- Helm chart: `dify-0.38.0`
- Kubernetes deployment: `dify-k8s-api`
- Business endpoint: `/v1/chat-messages`

### ✔️ Expected Behavior

When network capacity is degraded, Dify should enforce explicit timeout and retry budgets and return a stable, diagnosable error or controlled fallback.

Network slowness should not result in an unexplained generic HTTP `500` response or excessive request latency. Requests should terminate within a documented latency budget.

### ❌ Actual Behavior

The `network_bandwidth` fault was executed in three independent valid trials. All `3/3` trials observed business degradation.

- The first observed request returned HTTP `500` after approximately `7.9 seconds`.
- A later request recovered with HTTP `200`, but took approximately `18.7-20.6 seconds`.
- The baseline latency for the same Chatflow request was approximately `1.5-1.7 seconds`.
- The probe recorded `transport_error=true` on the failed sample. In this test harness, this flag means that the HTTP helper returned an error field; it does not by itself prove that no HTTP response was received.
- The business path recovered after the bandwidth limit was removed.

Detailed sanitized runtime artifacts are available upon request.

Start by reproducing the bandwidth fault against the `/v1/chat-messages` endpoint on the `dify-k8s-api` deployment, then trace the API request path and its timeout and retry configuration. Done means degraded network conditions produce a bounded, diagnosable response or controlled fallback instead of an unexplained HTTP 500 or excessive latency.

Written by the indexing model from the issue text.