Agent configuration queries MCP providers through the builtin credential endpoint and returns 500

### 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 (self-hosted deployment)

### Cloud or Self Hosted

Self Hosted (Docker)

### Steps to reproduce

## Steps to reproduce
1. Deploy Dify 1.16.0 in a self-hosted environment.
2. Create an MCP provider under **Tools > MCP**. In this case the provider name is `TAPD-TEST` and its server identifier is `tapd-server-test`.
3. Complete the MCP authorization successfully and add one of its tools to an Agent configuration.
4. Open the Agent configuration page and inspect the network requests made by the tool authorization/credential UI.
5. The UI requests:
`GET /console/api/workspaces/current/tool-provider/builtin/tapd-server-test/credential/info`

The MCP record exists in `tool_mcp_providers`, has `authed = true`, and has stored credentials. There is intentionally no matching row in `tool_builtin_providers`.

Response:
```json
{
"message": "Internal Server Error",
"code": "unknown",
"status": 500
}
```

## Additional context
The `builtin/{provider}/credential/info` route resolves the provider through `ToolManager.get_builtin_provider(...)`. An MCP server identifier is neither a builtin provider nor a plugin provider, so the lookup fails and is surfaced as a 500.

### ✔️ Expected Behavior

MCP providers should not be passed to the builtin/plugin credential-info workflow.

When an Agent uses an MCP tool, the UI should use the MCP provider state and MCP routes (`/workspaces/current/tool-provider/mcp/...`) for its configuration and authorization. It should not request `/tool-provider/builtin/{server_identifier}/credential/info`, and opening the Agent configuration must not produce a 500.

### ❌ Actual Behavior

The Agent configuration triggers a request to the builtin credential-info endpoint with the MCP server identifier. The backend then tries to resolve the MCP server as a builtin/plugin provider and returns HTTP 500. The MCP provider itself exists, is authorized, and has stored credentials.

Start by tracing the Agent configuration UI request to `/tool-provider/builtin/{server_identifier}/credential/info` and the backend `ToolManager.get_builtin_provider(...)` lookup. Compare this with the MCP routes under `/workspaces/current/tool-provider/mcp/...`; done means MCP tools use their MCP provider state without the builtin request or an HTTP 500.

Written by the indexing model from the issue text.