[bug] @deepseek-ai/dsh-api-session-controller 的 session/list 默认全量加载，随使用数据逐渐爆炸，建议增加分页、懒加载机制

[yuzh2001]

建议给 @deepseek-ai/dsh-api-session-controller 的 session/list 做成懒加载：首屏只给摘要，展开分组和点开对话时再取详情

一、问题：会话只会越攒越多，而列表接口没有任何上限

@deepseek-ai/dsh-api-session-controller 的 session/list 一次返回全部会话，既没有条数上限，也没有分页：

export interface SessionListRequest {
    readonly cursor?: string;   // 签名里预留了游标
}

// @deepseek-ai/dsh-api-session-controller, lib/index.js
async list(_request, signal) {          // 但参数收下没用
    return { items: await this.listState.list(signal) };
}

这意味着这个接口的开销只会随使用时间单调增长，不会自己收敛。

近期我在重度使用dsh，我的实验服务器上存了 1075 个会话，实测：

项目	数值
未压缩的返回体	1.33 MB
gzip 压缩后（浏览器「传输大小」一栏看到的量）	323 KB
其中属于各种派生字段（projections.values）的部分	80.8%
行本身的字段只用掉	17.2%

也就是说，真正属于"会话列表"的信息只占六分之一，其余全是跟着走的附加内容。用得越久，这个数字越大。

二、为什么现在的做法没必要：前端本来就是折叠展示的

@deepseek-ai/dsh-client-ui-workspace 里写死了：

/** Session rows visible per Workspace before the local overflow control. */
const COLLAPSED_SESSION_LIMIT = 5;

侧边栏里每个工作区默认只显示 5 条会话，其余的要人点"展开"才看得见。也就是说首屏上人眼真正会看到的行非常少，而接口把全部 1075 行连同附加内容一起传了过来。

附加字段里最夸张的是 turnOutline，占整个返回体的 34.2%。它的内容是每一轮对话一条记录，每条带问题的前 50 个字符和回答的前 120 个字符：

"turnOutline": [
  { "turn": 1, "seq": 5,
    "prompt": "看一下reference，codesharp和scalar的设置里环境的最大长度都是多少？craf…",
    "response": "两篇论文我都逐字查过了，结论先说：**只有 SCALAR 明确写了…" },
  …
]

它是给聊天窗口右侧那个"跳到第几轮"的导航用的。只有人真的点开某一条对话、并且需要翻它内部的轮次时，这份内容才有意义。一进页面就把全部会话的轮次摘要都载进来，纯属白传。

同样的道理也适用于 tokenUsage、contextPressure、contextBreakdown、sessionStats、todos、plan、inbox、modelSelection、subagentCatalog 这些 —— 它们都是"某一条对话自己的细节"，不是"列表要显示的东西"。

三、建议

1. 列表首屏只返回摘要行

只给真正要用来渲染侧边栏的东西：会话号、最后活动时间、是否在跑、是否空白、工作目录、父会话、来源、以及标题。按实测，这部分只占全部内容的一小部分。

2. 分组展开时再取那一组

分组本身已经有了（侧边栏就是按工作区分组的），而且展开状态前端已经记着（setGroupExpanded 会把展开的工作区写进浏览器本地状态）。所以很自然的分工是：

• 首屏：每个工作区只要够填那 5 行的摘要（要不就按"最近活动的 N 条"取）
• 人点"展开"某个工作区时：再取这一个工作区的完整列表
• cursor 字段已经预留了，实现它就能做到，不需要新增协议

3. 对话细节改成点开时才取

turnOutline 以及其他"某一条对话自己的细节"，改成人点开那条对话时再取。聊天窗口本来就有 useProjection("turnOutline") 这条实时订阅，扩展一下让它负责"需要时才去取"就行。