fix: route MCP provider credential lookup away from builtin auth (fix #40612)

[Sskift]

Summary

Fixes #40612.

getProviderCredentialType (in web/features/agent-v2/agent-detail/configure/tool-provider-catalog.ts) classified any tool provider with stored team_credentials as credential type api-key, checking team_credentials before provider.type. An MCP provider that had stored team credentials was therefore misclassified as api-key, which routed it into the plugin-auth UI path and set credentialVariant: 'unauthorized'. UnauthorizedCredentialStatus then mounts usePluginAuth, whose useGetApi always builds URLs like /workspaces/current/tool-provider/builtin/<provider>/credential/info. For an MCP server, <provider> is the MCP server id (not a builtin/plugin provider id), so the backend returns 500.

Root cause

The team_credentials check in getProviderCredentialType was not scoped to builtin providers, so any provider type (including mcp) with stored team credentials resolved to 'api-key'.

Fix

Scope the team_credentials → 'api-key' classification to CollectionType.builtIn only, mirroring the existing oauth2 branch. MCP (and custom/workflow/model) providers now resolve to no credential type, so they no longer enter the plugin-auth path.

Testing

• Added web/features/agent-v2/agent-detail/configure/__tests__/tool-provider-catalog.spec.ts covering getProviderCredentialType for builtin (api-key / oauth2) and MCP (with/without team_credentials) providers.
• RED: before the fix, the MCP-with-team_credentials case returned 'api-key' and the test failed (expected 'api-key' to be undefined).
• GREEN: after the fix, the focused spec passes (5/5).
• Regression: pnpm --config.verifyDepsBeforeRun=false test configure → 26 files, 379 tests passed.

Note: this addresses the primary root cause (credential-type misclassification). The related hardening suggested in the issue — adding an isBuiltinProvider guard on the UnauthorizedCredentialStatus render path in provider-tool/item.tsx so non-builtin providers short-circuit before usePluginAuth mounts — was intentionally left out of this PR to keep the change atomic and scoped to the actual 500 trigger; it can be a follow-up if maintainers want defense-in-depth.

From Claude

[gylucio]

I reproduced #40612 on a self-hosted Dify 1.16.0 deployment and locally verified this branch (9598529c6d).

Focused test:

pnpm --dir web exec vitest run features/agent-v2/agent-detail/configure/__tests__/tool-provider-catalog.spec.ts
Test Files  1 passed (1)
Tests       5 passed (5)

The provider-catalog change prevents an MCP provider with stored team credentials from being classified as a plugin api-key credential. Test environment: macOS. AI-assisted verification: Codex.