[Refactor/Chore] Defer tracing configuration loading on the app overview

### 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 refactors or chores; 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.

### Description

The app Overview currently loads the tracing status and fetches each tracing provider configuration as soon as the page mounts. With ten supported providers, opening the Overview triggers eleven tracing-related HTTP requests even when the user never opens the tracing settings.

Consolidate the initial state into a lightweight summary request, load detailed provider configurations only when the configuration popover is opened, and use a batch details endpoint instead of one request per provider. The configuration popover and provider modal should also be loaded on demand.

### Motivation

Tracing is an optional configuration surface, but its current eager loading adds avoidable network traffic and JavaScript work to every Overview visit. The change reduces the initial tracing request count from eleven to one, while preserving existing configuration, provider selection, enable/disable, permission, tenant isolation, and secret-obfuscation behavior.

### Additional Context

Expected request behavior:

- Overview mount: one tracing summary request.
- Configuration popover open: one batch details request.
- No detailed configuration request before the popover is opened.

Locate the app Overview tracing-status and provider-configuration loading, then trace how the configuration popover and provider modal are opened. Verify the request sequence against the stated behavior: one summary request on mount, one batch details request when the popover opens, and no detailed request beforehand.

Written by the indexing model from the issue text.