[Feature]: 能力空白：没有 demo 把"多用户 + 同会话多端同步"拼起来

## 摘要

在 `agentscope-examples` 里，**没有任何一个 demo 同时具备"多用户"和"同一会话多端实时同步"**（即"在另一个设备打开同一个会话能实时看到更新"的体验，类似钉钉）。所需的基础能力其实都有，但没有参考应用把它们组装起来。

## 当前覆盖情况

| 能力 | 现状 |
|---|---|
| 多用户 + 鉴权 | `agentscope-dataagent`（`AuthController` / `UserController` / `AdminUserController`） |
| 多渠道触达 | `dataagent`、`agentscope-service`（aistiod） |
| 按 session 隔离（channel 写在 gateKey 里） | 所有 demo 都有——且是有意设计 |
| 历史连续性（打开时拉历史） | 已支持（`SessionStore` + history API + `GET /chat/session`） |
| **同一会话的多端实时同步** | **没有——既无 demo，也无开箱模块** |

## 把"多端同步"说精确

"多端同步"其实混了三层，缺的是第③层：

1. **多用户**——已覆盖（dataagent）。
2. **多渠道触达**——已覆盖（dataagent、service）。
3. **同一会话多端实时同步**（钉钉式：一个会话在多个设备上实时镜像）——**未覆盖**。

## 为什么值得做

- **渠道隔离是对的**——对 B2B / 渠道型 agent 场景（本项目主战场），钉钉私聊和网页控制台**就该**是两个 session。
- **消费级 AI 对话**（个人助手多端实时同步）是另一种常见形态，当前 demo 对它支撑不足。来评估框架的人找不到参考，只能从零自研交付层。
- 这是**交付层**的空白，不是 agent 内核的问题——但恰恰是用户最容易先踩到的点。

## 建议范围（供讨论）

一个参考 demo：

1. 把 **agent 回复**（token / done / error，不只是工具事件）publish 到每会话的广播通道。
2. 同一 `sessionKey` 支持**多个并发订阅端**（WebSocket 或常驻 SSE）。
3. 支持**迟到的订阅者补全**——先拉历史，再接实时流。
4. 给出**单实例方案**（进程内 `Sinks`）与**生产方案**（跨副本用 Redis Pub/Sub 等）的说明。

最小可行改动其实不大：在 controller 的流合并处，把回复也 publish 进每会话 sink；再开一个订阅端点。难的是跨副本的一致性 / 有序 / 断线重连，那部分属于生产方案。