[Refactor/Chore] Defer MCP favicon parsing dependencies from the Integrations entry

Start with web/app/components/integrations/index.tsx and trace the listed section-renderer.tsx, MCP modal, and use-mcp-modal-form.ts chain to tldts. Run the Vinext browser build with Rolldown analysis, then compare production requests before and after opening MCP and entering a valid server URL. Done means the model-provider entry no longer eagerly includes the parser while MCP favicon loading, errors, stale results, and registrable-domain behavior remain correct.

Self Checks

• I have read the Contributing Guide and Language Policy.
• This is only for refactors or chores; if you would like to ask a question, please head to Discussions.
• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report, otherwise it will be closed.
• 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
• Please do not modify this template :) and fill in all the required fields.

Description

Defer the MCP favicon domain-parsing dependency instead of including it in the shared Integrations entry. The model-provider section currently shares a static dependency chain with MCP create/edit UI:

web/app/components/integrations/index.tsx
  → section-renderer.tsx
  → tool-provider-list.tsx
  → tools/mcp/index.tsx
  → tools/mcp/modal.tsx
  → tools/mcp/hooks/use-mcp-modal-form.ts
  → tldts

section-renderer.tsx switches between sections at runtime but statically imports their implementations. In use-mcp-modal-form.ts, getDomain is only used by the asynchronous URL blur handler for a newly created MCP server, to construct a favicon URL.

Rolldown DevTools confirms:

• tldts 7.4.13 contributes 302,095 bytes, directly imported by the MCP form hook.
• tldts-core 7.4.13 contributes approximately 16 KB.
• Both the Integrations entry and MCP modal/form modules appear in integrations-BG8QSHyt.js. The final file is 549,378 bytes, approximately 179,461 bytes gzip.

These package contribution metrics and final chunk sizes have different scopes. The entire chunk is not removable, and these figures are not measured production transfer or guaranteed savings. This finding does not imply the datasets initial route downloads the Integrations chunk.

Reproduction:

1. Build the Vinext browser target with Rolldown analysis enabled.
2. Inspect tldts in Packages and follow its importer to the MCP form hook.
3. Inspect the Integrations chunk's module list and the source chain above.
4. Verify production requests on /integrations/model-provider before opening any MCP UI.

Motivation

Users visiting unrelated Integrations sections should not need the MCP favicon parser before using that functionality.

Possible focused fixes are to dynamically import tldts on the valid URL blur action or lazily load MCP dialogs while removing other eager paths to the form hook. A broader section split is another option if route measurements justify it.

Acceptance criteria:

• The model-provider Integrations entry no longer statically contains the MCP-only domain parser.
• MCP create/edit and favicon retrieval still work, including loading/error behavior and safe handling of stale asynchronous results.
• Preserve existing registrable-domain semantics: URL.hostname is not automatically equivalent for subdomains and public suffixes.
• Compare before/after production requests and build output, including first opening MCP and entering a valid server URL.

Additional Context

Measured on a local Dify 1.17.1 development branch based on 06e473015a9a1abb71da88ac0a0e92d96a992008, with local DevTools integration patches, using Vinext 1.0.0-beta.10, Vite+ core 0.3.2, and Node 24.21.0. Browser analysis session: sid_4_1789651325793. Recheck against current main before implementing.