Plugin daemon restart is exposed as HTTP 400 invalid_param

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

Dify version: `1.17.0`

### Cloud or Self Hosted

Self Hosted (Source)

### Steps to reproduce

1. Deploy Dify and configure a working Chatflow with an installed model plugin.
2. Verify that the Chatflow request returns HTTP `200` with the expected response shape.
3. Send the same request while restarting the `plugin-daemon` container.
4. Record the API response status, error code, plugin-daemon readiness, pod restart count, and timestamps.
5. Wait for the plugin runtime to become available and send the same request again.
6. Repeat the test after restoring the deployment state.

Environment

- Dify version: `1.17.0`
- API image: `langgenius/dify-api:1.17.0`
- Deployment platform: Kubernetes
- Namespace: `dify-k8s-lab`
- Plugin daemon replicas: `1`
- Business endpoint: `POST /v1/chat-messages`
- Chatflow mode: `advanced-chat

### ✔️ Expected Behavior

If the request is valid and the plugin daemon is temporarily unavailable, Dify should return a documented service-availability or dependency error, such as HTTP `503`, rather than HTTP `400 invalid_param`.
The response should clearly indicate that the failure is transient and may be retryable. It should not imply that the client needs to change a valid request.

### ❌ Actual Behavior

During the restart window, the valid Chatflow request returns responses such as:

```text
HTTP 400
error code: invalid_param
```

After the plugin daemon and its plugin runtime recover, the same request returns HTTP `200` with a valid Chatflow response.

Observed across three independent valid trials:

- Trial `0018`: three consecutive `400 invalid_param` responses, then `200`.
- Trial `0019`: six consecutive `400 invalid_param` responses, then `200`.
- Trial `0020`: ten consecutive `400 invalid_param` responses, then `200`.
- All three trials recovered successfully.

## Initial Root-Cause Evidence

The plugin-daemon logs captured during the failure contain the following sequence:

```text
no plugin states found in redis
no plugin available nodes found
no available node, plugin runtime not found
```

The daemon also logged the plugin dispatch request as HTTP `404` while the runtime was unavailable. This supports the following failure chain:

```text
plugin daemon restart
-> plugin runtime is not registered or not restored yet
-> Redis has no state for the plugin runtime
-> plugin daemon has no available node and returns 404
-> API exposes the dependency failure as 400 invalid_param
```

The immediate cause is therefore a temporary plugin-runtime availability or recovery window, not invalid user input. The exact source-level cause of the missing Redis state and the API's error mapping still needs to be confirmed in the startup/registration and API exception-handling paths.

Related issues, including #36244 and #36367, discuss plugin-daemon failures, but they do not cover this restart-triggered Chatflow behavior, where repeated `400 invalid_param` responses are followed by successful recovery.

Start by tracing the API exception-handling path for POST /v1/chat-messages and the plugin-daemon startup and registration paths described in the report. Inspect how missing Redis plugin state and daemon HTTP 404 responses are mapped; done means a temporary runtime outage produces a documented retryable dependency or service-availability response instead of 400 invalid_param, while recovered requests still return 200.

Written by the indexing model from the issue text.