Feature Request: Expose agent/tool configuration via API (eliminate need for direct DB access)

## Problem

External platforms that integrate with Dify (observability, backup, governance tools) currently need **direct access to Dify's PostgreSQL database** to discover agent configurations. This is fragile and undesirable for several reasons:

- **Schema coupling**: External tools break when Dify's internal DB schema changes between versions
- **Security**: DB credentials must be shared with external services, bypassing Dify's auth layer
- **Deployment constraints**: In production/K8s environments, the Dify DB is often network-isolated and not directly accessible to sidecar services
- **No change notifications**: External tools must poll the DB with raw SQL, with no efficient way to detect config changes

## What we currently extract from the DB

Our integration (a sidecar service called `dify-connector`) polls Dify's DB every 60s and extracts:

| Data | DB tables | Fields needed |
|------|-----------|---------------|
| **Apps/Agents** | `apps`, `app_model_configs` | `id` (app UUID), `name`, `mode` (agent-chat, advanced-chat, etc.), `description`, `icon`, `icon_background` |
| **LLM model config** | `app_model_configs` | `model_provider`, `model_name`, `completion_params`, `pre_prompt`, `agent_strategy` |
| **Tools** | `app_model_configs.tools` (JSON) | `provider_id`, `provider_type`, `tool_name`, `tool_parameters`, `credential_id`, `enabled` |
| **Tool providers** | `tool_providers` (plugins) | `provider_id`, `name`, `type` (builtin/plugin/mcp), `server_url`, `tools` |
| **API tokens** | `api_tokens` | `token`, `app_id` |

## Proposed solution

A first-party Dify API endpoint (or set of endpoints) that exposes this configuration:

```
GET /v1/apps/discovery
```

Returns all apps with their model configs, tools, and tool providers in one response. Alternatively, granular endpoints:

- `GET /v1/apps` — list apps with mode, description, and model config
- `GET /v1/apps/{app_id}/tools` — tools enabled for an app
- `GET /v1/tool-providers` — installed tool providers with their tool manifests

### What we need in the response

```json
{
"apps": [
{
"id": "390bdd58-bc95-44b0-bbc0-304cb7535459",
"name": "NexusCRM",
"mode": "agent-chat",
"description": "AI Account Manager for B2B Sales",
"model": {
"provider": "langgenius/deepseek/deepseek",
"model_name": "deepseek-chat",
"completion_params": { ... },
"pre_prompt": "You are NexusCRM, ...",
"agent_strategy": "function_call"
},
"tools": [
{
"provider_id": "beersoccer/mem0ai/mem0ai",
"provider_type": "builtin",
"tool_name": "search_memory",
"tool_parameters": { ... },
"credential_id": null,
"enabled": true
}
]
}
],
"tool_providers": [
{
"provider_id": "beersoccer/mem0ai/mem0ai",
"name": "Mem0 AI",
"type": "builtin",
"tools": [ ... ]
}
]
}
```

### Key requirement: include `app_id` (the app UUID)

The `app_id` is critical for trace correlation. Dify's OTEL exporter already includes `app_id` in trace metadata, but there's no API to look up which agent an `app_id` belongs to. If this API exposes the app UUID, external platforms can join traces to agents without touching the DB.

Start by reviewing the existing app, model-config, tool-provider, and OTEL exporter API entry points, then compare their authentication and response boundaries with the requested discovery data. Clarify the endpoint shape and safe fields with maintainers, especially credentials and tokens. Done means authenticated API access exposes app_id and the required configuration without direct database access, with coverage for the agreed response.

Written by the indexing model from the issue text.