[Bug] 拖动侧边栏分栏线时主会话框左右抖动（0.12.1 回归）

[KaramachiA217]

What happened

升级到 0.12.1 后，拖动右侧边栏与主会话区之间的分栏线（调整侧边栏宽度）时，主会话框（会话输出区 + 输入栏）会异常地左右抖动——它没有平稳地跟随分栏线移动，而是在拖拽过程中来回晃动。始终可复现。

What I expected

拖动侧边栏分栏线时，主会话区应平滑地让出/收回宽度，跟随分栏线稳定移动，不应出现左右抖动或来回晃动。

Steps to reproduce

1. 打开任意一个会话（dsh web）
2. 鼠标按住右侧边栏左边缘的分栏线（panel resize handle）左右拖动
3. 观察主会话区（会话输出与输入栏）：在拖拽过程中主会话框左右抖动，而不是平滑跟随

Additional context

• 在升级到 0.12.1 之前（0.11.0）没有此现象，升级后出现，且稳定复现
• 抖动方向为水平方向（左右），发生在拖拽的整个过程中，越快速拖拽抖动越明显
• 疑似与侧边栏宽度变化时主会话区的过渡动画（transition）未能及时禁用有关：拖拽期间宽度变量逐帧更新，但布局过渡仍在生效，导致主会话区以动画方式追赶目标宽度，产生来回抖动
• 相关环境：Windows 11，Chrome 系浏览器，dsh web

[KaramachiA217]

补充：来自本地 0.12.1 安装包的分析（供维护者参考，非定论）：

• 侧边栏宽度通过 CSS 变量 --dsh-sidebar-width 作用于布局推挤（#root 的 margin-right），该规则声明了 ransition: margin-right ...（慢速缓动）。
• 拖拽期间宽度变量在 rAF 节流下逐帧更新（pointermove → scheduleDrag → applyDrag）。
• 代码里通过 �ody[data-dsh-sidebar-dragging] 属性在拖拽时禁用该过渡，但这个属性是经 React state（setDraggingWidth(true)）+ useEffect 异步写入的——从 pointerdown 到 body 属性生效之间存在一帧左右的窗口；同时 pointermove 可能已开始逐帧改写宽度变量。
• 在该窗口内（以及任何 ransition: none 未能及时生效的路径上），margin-right 的过渡动画会追赶每帧变化的目标值，表现为主会话区左右抖动；拖得越快、帧间差值越大，抖动越明显。

建议排查方向：拖拽开始时同步（非 React state 延迟）禁用过渡，或改为在拖拽期间对 #root 内联写入 ransition: none，与宽度变量同一帧提交。

[KaramachiA217]

补充调查结果（对本地 0.12.1 安装包源码的只读分析，修正上文的部分猜测）：

布局/拖拽机制澄清

• 主会话区宽度联动是「CSS 变量 + margin 挤压」（layout push）：#root { margin-right: var(--dsh-sidebar-width) } 带慢速 transition；右侧面板 fixed 覆盖，靠撑大 margin 让 AppFrame 中心列（主会话输出+输入条）让出宽度。
• 宽度拖拽条 = .panelResize（右侧面板左缘 8px、col-resize）。拖拽中只写 DOM 不回 store：pointermove → scheduleDrag → rAF 每帧一次 applyDrag（同时写面板内联宽度、--dsh-sidebar-width/--dsh-sidebar-height、底部面板 right）；松手才提交一次 store（setWidth）→ 200ms 防抖持久化。代码注释明确：避免每次 move 都重渲染两个工作台（终端/编辑器）造成可见拖拽延迟。
• 过渡禁用（.panel[data-dragging]、body[data-dsh-sidebar-dragging] #root）都是 React effect 异步切换，不是同步写在 pointer 事件里。

最可能的抖动机制（修正）

1. 松手瞬间（最可疑）：stopDragScheduling() 会取消尚未执行的 rAF 写入——若 pointerup 时还有一帧 pending，DOM 保留的是上一帧宽度，而提交值是当前指针位置宽度（快速拖拽差一帧 ≈ 数 px～数十 px）。随后过渡重新启用（data-dragging/body 属性移除），layout-push effect 把 CSS 变量写为提交值 → 面板宽度与主会话区 margin 以「瞬时跳变 + 过渡回弹」错位，肉眼即"松手那一下左右晃"。
2. 开始瞬间：startWidth = state.width（已提交值），若紧跟在折叠/展开动画后（margin 过渡还在播放中），实际渲染宽度 ≠ 提交宽度，且 effect 设置 body[data-dsh-sidebar-dragging] 有延迟窗口 → 第一帧宽度写入时过渡仍启用 → 主会话区以缓动追赶指针 → 滞后/过冲；整段拖拽还以错误 startWidth 为基准。
3. 内部 divider 拖拽（代码自述的可见延迟）：工作台内部 Divider 每次 pointermove 直接 store.reduce(resizeSplitIn)（无 rAF 批处理、无松手提交）→ 两个工作台整树重渲染（xterm/CodeMirror/资源树/子代理轮询全部保持挂载）+ 每 ≤200ms 全量 localStorage 写入。会话有活跃输出时主线程被占用 → 拖拽帧写入被推迟 → 卡顿/抖动观感放大。这与"面板拖拽特意改成只写 DOM + 松手提交"形成双轨架构不一致。

排除项（已核对）：宽度只有一条写链（拖拽 → CSS 变量 → margin-right），无 A↔B 写回循环；store 拖拽中不提交不持久化，防抖不会回放旧宽度；centerRect 拖拽中暂停测量；mid-drag React 重渲染不覆盖内联样式。

关于"0.12.1 回归"的提示：包内无 CHANGELOG/docs；README 显示 v0.12.1 改动集中在服务化基座（状态订阅、tab 角标、生命周期回调、meta 跨刷新持久化、定向打开）+ 修复（#31 崩溃边界、403 信任栅栏、Windows HTML 盘符）。布局/拖拽管线本身在 0.12.1 无改动；若确实是 0.12.1 才出现，嫌疑更可能落在持久化/服务化重做（每会话防抖、meta 持久化、reduceFor 定向打开写非当前会话）与拖拽/持久化边界的交互，而非拖拽管线本身。