[Refactor/Chore] Preserve the Amplitude lazy-loading boundary in tracking utilities

Start by building the Vinext browser target and inspecting the client manifest’s static imports. Trace web/app/components/base/amplitude/lazy-amplitude-provider.tsx, amplitude/index.ts, utils.ts, init.ts, app/components/main-nav/layout.tsx, and CloudAnalyticsLayoutBoundary. Done means the SDK implementation is not statically pulled in by lightweight consumers, while consent, initialization, identity, opt-out, registration flushing, and synchronization behavior remain intact; compare build graphs and transferred JavaScript.

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

Keep Amplitude SDK implementation imports behind the analytics activation boundary. The provider is dynamically imported, but common tracking utilities bypass that boundary through static imports:

1. web/app/components/base/amplitude/lazy-amplitude-provider.tsx dynamically imports AmplitudeProvider.
2. amplitude/index.ts also re-exports tracking and identity functions from utils.ts.
3. utils.ts statically imports @amplitude/analytics-browser and getIsAmplitudeInitialized from ./init.
4. init.ts statically imports both @amplitude/analytics-browser and @amplitude/plugin-session-replay-browser.
5. Navigation/account UI and external-service synchronization use these utilities.

A local Rolldown client build confirms the static manifest chain:

app/components/main-nav/layout.tsx
  → _help-menu-D6_0F4Dx.js
  → _utils-UCOVMtae.js

CloudAnalyticsLayoutBoundary also statically imports the utils chunk. That shared chunk contains 187 modules and is 337,689 bytes, approximately 92,891 bytes gzip. These are shared-chunk sizes, not guaranteed savings or measured production network transfer. Several replay recording modules remain dynamic imports; their entire package sizes should not be counted as eager payload.

Reproduce by building the Vinext browser target, inspecting the client manifest's static imports, and tracing the utilities above. The provider's dynamic import alone does not prevent the SDK from being reached statically elsewhere.

Motivation

Checking consent or API-key availability before SDK calls does not defer static imports. This is a loading/performance issue, not evidence of analytics events being sent before consent.

Suggested direction: keep initialization status and listeners in a lightweight module, and lazily load the SDK implementation only when analytics is eligible to activate. Audit utility/barrel imports so they do not reintroduce an eager path.

Acceptance criteria:

• Verify production requests with consent denied, analytics disabled/no API key, and consent granted.
• Ensure lightweight tracking/status consumers do not statically pull in the SDK initialization implementation.
• Preserve registration-event flushing, identity synchronization, initialization notification, opt-out behavior, and consent transitions.
• Compare before/after build graphs and transferred JS; do not claim the entire shared chunk as savings without measurement.

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 (12,219 modules). Recheck against current main when implementing.

Related closed work: #33887 discussed lazy initializers and dev cold-load performance; #38514 separated bootstrap/external-service responsibilities. This report specifically tracks the remaining static SDK path in production build output.