Agents configure page throws 500: credential schema of a custom API tool provider is requested via the builtin tool-provider route (PluginNotFoundError)

### 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-rc1 (docker compose; plugin-daemon 0.6.3-local, agent-backend 1.16.0-rc1)

### Cloud or Self Hosted

Self Hosted (Docker)

### Steps to reproduce

1. Create a **custom API tool provider** (Tools → Custom → import OpenAPI schema) with
**API Key header** authorization. Test calls succeed.
2. On the **new Agents platform**, create an agent and add several tools from this
custom API tool provider.
3. Open the agent's configure page: `/agents//configure`.

An `Internal Server Error` toast pops up on every page load (the request is retried
3 times), and the "Configuration" menu item shows a permanent warning badge.
**Chat and actual tool invocation work fine** — the issue is console-only.

### ✔️ Expected Behavior

The configure page loads without errors. Credential information for an `api`-type
tool provider should not be fetched through the builtin/plugin provider route.

### ❌ Actual Behavior

The configure page requests the credential schema of the **custom API tool provider**
through the **builtin** route:

```
GET /console/api/workspaces/current/tool-provider/builtin/730b5917-e9c5-43ae-9985-962361bc39fd/credential/schema/api-key → 500
Referer: http:///agents/019f6a2d-d92a-7d0a-a92e-4fc65b12ec2c/configure
```

`730b5917-e9c5-43ae-9985-962361bc39fd` is **not** a builtin provider — it is the id
of a row in `tool_api_providers`:

```
dify=# select id, name from tool_api_providers;
730b5917-e9c5-43ae-9985-962361bc39fd |

dify=# select id, provider from tool_builtin_providers;
(0 rows)
```

The api container therefore asks the plugin daemon for a plugin that can never exist
(`plugin_id=langgenius/730b5917-e9c5-43ae-9985-962361bc39fd`) and returns 500:

```
Exception on /console/api/workspaces/current/tool-provider/builtin/730b5917-e9c5-43ae-9985-962361bc39fd/credential/schema/api-key [GET]
Traceback (most recent call last):
...
File "/app/api/controllers/console/workspace/tool_providers.py", line 851, in get
BuiltinToolManageService.list_builtin_provider_credentials_schema(
...
File "/app/api/core/plugin/impl/base.py", line 389, in _handle_plugin_daemon_error
raise PluginNotFoundError(description=message)
core.plugin.impl.exc.PluginNotFoundError: req_id: 72be2f3cef PluginNotFoundError: plugin not found
```

In the agent's draft config (`agent_config_drafts.config_snapshot`) the tools are
stored **correctly** as `api` type, but with `credential_type: "unauthorized"`:

```json
{
"provider": "",
"provider_id": "730b5917-e9c5-43ae-9985-962361bc39fd",
"provider_type": "api",
"credential_type": "unauthorized",
"credential_ref": null,
"tool_name": "..."
}
```

So the configure page appears to treat every tool provider as builtin when it tries
to resolve/repair tool authorization (which also explains the warning badge). Note
that the backend only registers the credential-schema route for builtin providers —
`/workspaces/current/tool-provider/builtin//credential/schema/`
in `controllers/console/workspace/tool_providers.py` — there is no `api`-provider
equivalent, so this looks like a frontend routing bug (or missing api-provider
handling) in the new Agents configure page.

**Impact**: cosmetic but noisy — an error toast on every configure page open and a
permanent warning badge; runtime is unaffected because API tools use the
provider-level credentials stored in `tool_api_providers`.

Start at the Agents configure-page entry point for `/agents//configure` and trace the credential-schema request, then compare it with the builtin route in `api/controllers/console/workspace/tool_providers.py`. Reproduce with a custom API provider using API-key authorization; done when the page makes no builtin-provider request, loads without a 500 or warning badge, and existing tool invocation remains functional.

Written by the indexing model from the issue text.