Builtin tool credential endpoints return 500 for unknown provider identifiers

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

main (6208b33e), also reproduced on 1.16.0

### Cloud or Self Hosted

Self Hosted (Source)

### Steps to reproduce

Related to #39169 and #40612, but this report covers the remaining backend error handling after the frontend stops sending the invalid request.

1. Sign in to a self-hosted Dify workspace.
2. Request a builtin credential endpoint with an identifier that is not a builtin or plugin provider, for example:
`GET /console/api/workspaces/current/tool-provider/builtin//credential/info`
3. The same path occurs when the current Agent V2 bug sends an MCP server identifier to the builtin endpoint.

`ToolManager.get_builtin_provider()` falls back to `PluginToolManager.fetch_tool_provider()`. The plugin daemon raises `PluginNotFoundError`, which is not a `ValueError`, so the console API generic exception handler returns HTTP 500. The same risk applies to the builtin credential schema and credential-list endpoints.

### ✔️ Expected Behavior

An unknown or non-builtin provider identifier should produce a controlled 4xx response (consistent with the existing `ToolProviderNotFoundError` domain error), without surfacing an internal server error.

The frontend fixes in #40686 and #41088 should still prevent invalid requests from Agent V2; this backend guard is defense in depth for other callers.

### ❌ Actual Behavior

The request returns HTTP 500 with `PluginNotFoundError: plugin not found`.

A minimal fix is to translate `PluginNotFoundError` to `ToolProviderNotFoundError` at the `ToolManager.get_plugin_provider()` boundary, with a focused unit test. I can prepare the PR if a maintainer agrees and assigns this issue to me.

AI-assisted investigation: Codex.

Start at the ToolManager.get_plugin_provider() boundary and trace the builtin credential info, schema, and credential-list endpoints. Reproduce the request with an unknown provider identifier, then add the focused unit test mentioned in the issue. Done means the PluginNotFoundError path produces the existing ToolProviderNotFoundError behavior and a controlled 4xx response instead of HTTP 500.

Written by the indexing model from the issue text.