Show the plugin error message in the UI toast instead of the raw error envelope

### 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] 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] Please do not modify this template :) and fill in all the required fields.

### 1. Is this request related to a challenge you're experiencing? Tell me about your story.

While testing the credential setup for a tool plugin we maintain
(`apify/apify-integration`) in Dify Cloud, I pasted an invalid API token to
check what a user would see. The plugin raises a
`ToolProviderCredentialValidationError` with a message written for exactly that
situation:

> Invalid Apify API Token. Please check the token and try again.

What actually appears in the toast is the serialized error envelope with that
message buried inside it:

req_id: a7ce6eaf14 PluginInvokeError: {"args": {},"error_type":"ToolProviderCredentialValidationError","message":"Invalid Apify API Token. Please check the token and try again."}

This is not specific to our plugin. I hit the same thing while configuring
credentials for an unrelated third-party tool plugin, which matches what the
SDK does: it wraps every exception in this envelope regardless of type or
origin.

Nothing is broken here and the message is readable, so this is a polish request
rather than a bug. But it reads as internal debug output rather than as
something written for the person configuring the tool, and my worry is the
non-developer users building apps in Dify, who have to visually parse past
`{"args": {},"error_type":...}` to reach the sentence meant for them.

What I would like is for the toast to show the `message` field on its own, with
`req_id` and `error_type` still available for diagnostics but out of the
primary text. Since every plugin goes through this same path, that would improve
error UX across all of them at once, not just ours.

### 2. Additional context or comments

Tested on Dify Cloud (dify.ai) on 2026-08-10, with plugin
`apify/apify-integration` 1.0.4 and plugin SDK `dify_plugin` 0.4.5.

The message is already a distinct field by the time it leaves the plugin. The
SDK builds the payload in `dify_plugin/core/server/io_server.py`:

```python
data={
"error_type": type(e).__name__,
"message": str(e),
"args": args,
}
```

One thing I would like to confirm: is any of this controllable from the plugin
side? As far as I can tell the SDK wraps every exception in this envelope
unconditionally, with no hook to customize it, and raising a different exception
type only changes error_type. The only thing a plugin author controls is
str(e). If there is a plugin-side option I have missed, I am happy to fix it
on our end instead.

### 3. Can you help us with this feature?

- [ ] I am interested in contributing to this feature.

Start with dify_plugin/core/server/io_server.py, where the plugin error envelope is assembled, then trace the UI toast handling for credential validation failures. Confirm where the message is parsed and how req_id and error_type are retained for diagnostics. Done means the toast presents the message as its primary text without exposing the raw envelope.

Written by the indexing model from the issue text.