fix(chat): 发消息时的跳动、白屏与闪烁

[eeee0717]

这条 PR 做什么

合并原先的 #534 / #544 / #546 / #547 / #548 五层，方便一次读完。底下四层（#528 探针与假
provider、#529 按钮闪烁、#530 harness、#531 hook 分层）保持独立，本 PR 基于 #531。

主题是一条线：发出一条消息时，界面不该跳、不该闪、不该白。17 个提交按关注点分组，
按 commit 读能保住每一步的取证。

五组改动

1. 揭示前的定位只做一次（原 #534）

ready gate 的 effect 依赖 contentBaseHeight，流式每来一个 chunk 就重跑一次，于是整段流式
里每次都真滚一次。新建话题里内容还不满一屏，每次滚动都把 offset 拽回 0，表现为 offset 在
0 与 24/40 之间来回弹四五次。

修法是把 gate 的两半职责拆开：静默窗口继续守，「揭示前把列表放到正确位置」是一次性事件，
重跑只该重启窗口。readyGate 程序化滚动 75 → 1，offset 轨迹从 24→0→40→0→24→0… 变成
严格单调的 16→80→104→…→513。

2. 用户消息从输入框飞到钉顶落点（原 #544）

原来第一条消息没有入场动画，后续消息有。根因不在动画代码：入场靠的是钉顶滚动动画，
而新建话题内容不足一屏、可滚动距离恒为 0，滚动动画演不出任何东西。

改成由行自身的 transform 承担位移后，第一条和后续走完全同一条路径，那套专门去制造可滚动
距离的机制（animateFirstEnteringMessage + 分阶段释放锚点空间）整体作废并删除。

可见行程 616px 由两段分担、加起来恒等：钉顶滚动走「把旧内容让开」需要的那段（新话题 0px、
已有话题 306px），行的 transform 走剩下的。两段都走全程会是双倍距离；而为了避开双倍就把滚动
改成瞬时，会让整屏旧内容一帧切走（实测相邻两帧模板相关度 1.000→0.239）。

3. 新话题的第一条消息不再导航到空界面（原 #546）

open-topic 排在 createUserMessageWithPlaceholders 之前，聊天界面挂载时它要展示的那一轮
压根还不存在。用户看到的是：发送 → 白屏 → 转圈 → 消息才弹出来。

第一版修法是错的，留在这里当反面记录：我去调空状态覆盖层的不透明度规则，等于给一个不该
存在的窗口画更好的盖布，还引入了回归——续轮发送时空状态整块盖在已有对话之上，实测 6 帧 ≈
80ms、相关度峰值 0.807。

对的修法是让导航发生时目的地已经有内容：消息 id 在写库之前先铸出来（newMessageId()，同
$defaultFn 的 uuidv7 生成器），据此构造乐观 Message 发布进快照，然后才 emit 导航，最后按
同一批 id 落库。id 相等是硬前提——mergeMessagesWithOverlay 只按 id 全等去重、未命中即
append。遮罩、转圈、空状态覆盖层与 NewTopicScreen 整个屏随之删除。

	改前	改后
发送 → 气泡可见	~1.32s	~700ms
中间序列	空状态 → 遮罩+转圈 → 空白 → 气泡	空状态 → 空白 → 气泡
续轮命中空状态文案	6 帧 / corr 0.807	0 帧

顺带把 invalidate-topics 从 emitAndWait 挪进 onTurnPublished：它是一次 refetch，等的是
一份此刻没人在看的数据，却同时卡住导航前的窗口和 LegendList 的 onReady。

输入框也提到了分支之上（ChatScreen 现在是「header + 可换的中间那块 + 常驻 composer」），
顺带修掉一个既有隐性缺陷：原来两屏切换会让 ComposerProvider 整棵子树重挂，handleSend
失败时的草稿回滚写进空气。

4. 待生成占位与思考行等高 + 状态行收敛（原 #547）

行高由内容撑，而两个状态的内容不一样高：待生成占位只有 20px 的圆点，思考行是
max(圆点 20, 文字行高 24, chevron 16)。切换那一帧整条助手消息跳 4px（探针实测 48 → 52）。

给占位补一行不可见的 text-base 文字撑高。不能写死 24px：行高随字号档位变
（--ui-text-base--line-height），写死会在别的档位重新失配。

顺势把三处状态行（待生成占位、思考中、工具调用）收敛成 MessageStatusRow——它们占的是同一个
槽位，用户看到的就是它们相互切换，所以必须等高，那 4px 正是三份副本漂开的结果。
ToolPartTrigger 里四处 isDanger ? … : isWarning ? … : …（9 个 className 字面量）也一并
换成一张颜色查表。

5. header 助手按钮不再消失（原 #548）

topicId 一出现就硬切数据源，而 useTopic 还在 fetch，assistant 在那几百毫秒里是 null。
iOS 上 Stack.Toolbar 的 children 从 2 掉到 1，两个按钮一起走原生重建。

逐帧读 header 区暗像素：改前 437 → 261 → 110（几乎全空）→ 398 → 520，跨约 600ms；
改后 461 → 464，601 帧零变化。

验证

• bench 三轮全场景 0 违规，确定性表已随改动换代（见文档 diff）
• 全量 gate：pnpm typecheck 绿、pnpm test:app 309 套件 / 2901 测试全过、lint 0 error
• 逐帧取证一律读 ffprobe 的真实 pts_time（模拟器录制是 VFR，按固定 fps 反推会把几百
  毫秒的停顿算成几十毫秒）

已知边界

• 工具行没有真机取证：bench 三个场景都不含工具调用，第 4 组对它的改动靠结构等价 +
  ToolParts 单测覆盖。
• send-anchor 的 slide-in-flight 装填→开火从恒 0ms 变成 318–645ms，含义换了代：列表
  现在是带着这一轮挂载的，装填发生在挂载那一刻、开火要等第一次布局与 ready gate。逐帧看气泡
  真正停在起飞位只有 ~76ms，不能读成用户看到的停顿。文档里写了怎么判它是否回归。
• follow-up-turn 的 estimate-collapse 从 4 变 27 不是回归，是判据的精度问题（探针在
  尺寸没变时不发事件，判据于是把第二次真实增长当成首次实测）。两条修法记在文档里。
• 不在本轮范围：失败时留下的空话题行、ChatInput 的 selectedAssistantId 硬切、launch 后
  那段 260–350ms 主线程空档（全部 39 条历史轨迹都有，非本次引入）。