Support citations and source attribution in MCP responses for RAG-backed apps

### 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] I have searched for existing issues, including closed ones.
- [x] I confirm that I am using English to submit this report.
- [x] I have not modified the feature request template and have filled in all required fields.

### 1. Is this request related to a challenge you're experiencing? Tell me about your story.

When an Advanced Chat app backed by Knowledge Retrieval is published as an MCP server, `tools/call` returns only the generated answer text. The retrieved source metadata is persisted by Dify in `messages.message_metadata.retriever_resources`, but it is not exposed through the MCP response.

This makes downstream MCP clients such as Microsoft Copilot Studio and Teams unable to show citations, document attribution, page/section information, or other provenance to end users. For enterprise RAG use cases, users need to know which manual, policy, or document supports an answer.

For example, the current MCP response is effectively:

```json
{
"content": [
{
"type": "text",
"text": "Move your hand up or down below the inside rearview mirror to turn the reading light on or off."
}
]
}
```

However, the corresponding Dify message already contains retrieval metadata such as:

- dataset name
- document name
- segment content and position
- retrieval score
- document metadata (for example page, model, version, or other custom metadata)

The current MCP adapter for chat modes extracts only `response["answer"]`, and structured output contains only `{ "answer": ... }`. As a result, the provenance is lost at the MCP boundary.

It would be helpful if MCP responses for RAG-backed Chat / Advanced Chat apps could expose citations and source attribution, for example:

```json
{
"answer": "Move your hand up or down below the inside rearview mirror to turn the reading light on or off.",
"citations": [
{
"dataset_name": "vehicle-manuals",
"document_name": "vehicle-manual.xlsx",
"title": "Turning the reading light on and off",
"page": 272,
"score": 0.70,
"metadata": {
"model": "example-model",
"model_year": "example-year"
}
}
]
}
```

Suggested behavior:

1. Include deduplicated retrieval sources in `structuredContent.citations` for MCP clients that support structured output.
2. Optionally append a human-readable source section to `TextContent` for clients that only render text.
3. Avoid exposing internal-only identifiers by default, such as tenant IDs or segment internals; expose user-facing document metadata instead.
4. Preserve backward compatibility for apps without retrieval results and for older MCP protocol versions.
5. Support both blocking Chat / Advanced Chat responses and streaming Agent Chat responses where retrieval metadata is available.

### 2. Additional context or comments

Tested with self-hosted Dify 1.16.1 and an Advanced Chat app published as an MCP server. The knowledge retrieval itself works and `retriever_resources` are correctly saved in `message_metadata`; only the MCP response omits them.

Related but separate MCP transaction bug: #39787 and #40013. Those address `tools/call` failing with a closed SQLAlchemy transaction, not citation propagation.

This feature would improve trust, auditability, and compliance for enterprise MCP integrations, especially Microsoft Copilot Studio / Teams, where the MCP tool response is the only source available to the orchestrator.

### 3. Can you help us with this feature?

- [x] I am interested in contributing to this feature.