Enhancing Agent (LLM) context with message channel source and user identity information.

## 背景

当前 `@xmanrui/dsh-im` 插件在调用 `session.prompt` 时，只传递了以下字段：

```js
await this.rpc('session.prompt', {
sessionId,
mode: 'queue',
content,
clientTimeZone: Intl.DateTimeFormat().resolvedOptions().timeZone,
});
```

Agent（LLM）**无法感知**消息来自哪个渠道、发送者是谁、是单聊还是群聊。

## 痛点

1. **Agent 无法做渠道感知回复**：比如企微场景用更正式的口吻，微信群聊可以更活泼
2. **无法区分同一用户在不同渠道的对话**：同一个人在企微和微信同时跟 Agent 对话，Agent 上下文完全一样，容易混淆
3. **无法做发送者识别**：群聊场景下无法区分谁在说话
4. **业务逻辑受限**：比如「收到企微消息记录客户跟进日志」「收到微信消息用轻松语气回复」这类场景做不了

## 建议方案

### 方案 A：扩展 session.prompt 的 metadata（推荐）

```js
await this.rpc('session.prompt', {
sessionId,
mode: 'queue',
content,
clientTimeZone: ...,
source: {
channel: 'wecom', // wecom | weixin | feishu | dingtalk | qq | slack | telegram | discord | whatsapp
conversationType: 'direct', // direct | group
senderId: 'user123', // 可选，渠道内用户标识
senderName: '张三', // 可选，发送者昵称
botId: 'bot_xxx', // 可选，接收消息的 bot ID
},
});
```

Host 侧把这个 source 注入到 Agent 的 runtime context 中。

### 方案 B：在 content 前注入系统前缀（最小改动）

```js
const channelPrefix = [Channel: wecom | Type: direct | From: user123];
const enrichedContent = typeof prompt === 'string'
? ${channelPrefix}\n
: [{ type: 'text', text: channelPrefix }, ...prompt];
```

优点：改动小，Agent 在对话里就能看到。缺点：混在用户消息里，不够结构化。

## 补充说明

各渠道的 bridge 代码（wecom-bridge、weixin-bridge 等）已经有完整的渠道信息和发送者信息提取逻辑，内部 rpcIdPrefix 也按渠道区分了消息归属。只需把这些已有信息透传给 Agent。

## 预期收益

- Agent 可以根据渠道自适应语气和格式
- 多渠道并发对话时不会混淆上下文
- 群聊场景能区分不同发送者
- 为后续「按渠道路由不同...