多会话 UI 插件的渲染器扩展点（按 id 绑定会话 + 会话列包裹缝）

[lehhair]

多会话 UI 插件的渲染器扩展点（按 id 绑定会话 + 会话列包裹缝）

背景： 外部客户端插件（例如 PiUI 风格的多窗格对话界面）需要当前 web 客户端没有暴露的两项渲染器能力，且无法纯插件实现。本文是对两个最小、纯新增扩展点的提案。

缺口

分屏插件需要：

1. 包裹原生会话列（在其表面之上托管 N 个窗格）。
2. 把对话子树渲染到任意会话 id 上（每个窗格固定自己的会话，而全局选择独立移动）。

目前从插件侧两者都做不到：

• conversation 槽是 single、被 ui-conversation 的 ConversationRoot 独占，它声明了内部全部座位（conversation.session、conversation.composer、conversation.input.* 等）。阴影接管该槽意味着重声明（或失去）这些座位——槽系统拒绝第二个声明者；而框架里也没有任何"包裹会话列"的缝。
• 会话作用域槽只绑定当前选择（SessionProvider）。没有任何机制能把子树渲染到显式会话的 provide bundle 之下。
• 数据读面同样封闭：ISession 契约刻意只暴露行为动词（prompt/cancel/loadOlder/…），对话快照只能通过 useSession（当前选择通道）读取。插件连"按 id 绘制某会话的对话数据"都做不到。

提案（全部纯新增，零行为变更）

1. ISessions.session(id) —— 按 id 解析某会话的渲染层标准属性 bundle（当前选择通道的 by-id 孪生），与 binding() 一样懒创建作用域。未知 id 返回 undefined。
2. SessionScope 标准座位（web-react）—— 把子树渲染到显式会话的 provide bundle 之下（缺省 id = 静态无会话名册，用于 hero/新建对话表面），并采用与 SessionProvider 一致的 key={sessionId} 重挂载语义。与 by-id 选择器座位（useSessionById / useProjectionById）一起注入每个条目的标准 kit。
3. conversation.panes 缝（ui-layout）—— 框架在原生会话列外渲染的 root 作用域 single 槽：框架把自己的渲染授权以 owner render-prop（renderConversation）下放，fallback 就是原生会话渲染——无注册者时与今天逐字节一致。

座位保持可选：渲染器无条件注入，但类型由使用方合并（沿用现有 declare module 模式），因此基础 GlobalStandardProps 不变，现有测试零改动。

参考实现

三点的完整实现（含测试：SessionScope 绑定/缺省/迟到会话/重挂载行为、host 面接线、缝 fallback、运行时 session/emptyInfo 用例——500+ 客户端测试全绿）已就绪，可作为 PR 提交。主要消费方是分屏插件：把原生会话渲染进各自独立的窗格。

给维护者的问题： 这个方向是否符合 web 客户端的路线图？是否有更优的替代形态（例如不同的缝形状，或一个通用的"在这里渲染会话 X"原语）？

（分屏上下文：dsh-split-panes —— https://github.com/lehhair/dsh-split-panes）