fix(desktop): disable scroll animation for reduced motion

[Colafornia]

English

Summary

Maka already has one Desktop policy for programmatic scroll motion. It follows the operating system’s reduced-motion preference and disables animation during deterministic E2E capture.

Several navigation paths bypassed this policy. They used a hard-coded smooth value or an implicit smooth fallback.

As a result, these interactions could still animate when the user requested reduced motion:

• jumping to a search result in the transcript
• navigating with the prompt anchor rail
• revealing a turn outside the progressively mounted transcript window
• locating an entry in the memory document editor

This PR routes these interactions through the existing motion policy. Programmatic scrolling now follows the same native desktop convention across the application.

Refs #2084

Root cause

The main conversation already passed readScrollMotionBehavior() into ChatView, but this value did not reach every internal navigation path.

PromptAnchorRail and useProgressiveTurnMount used hard-coded smooth scrolling. useChatScroll also supplied its own smooth fallback.

The quote companion omitted the policy when rendering ChatView. Memory document navigation used another hard-coded smooth scroll.

These independent defaults made the shared policy optional in practice and allowed new call sites to bypass it silently.

Changes

• make ChatView.scrollBehavior required so each host must choose the motion behavior explicitly
• pass the selected behavior to search-result navigation, prompt anchors, and progressive turn reveal
• use readScrollMotionBehavior() in the quote companion and memory document editor
• remove local hard-coded and fallback smooth behavior
• reuse the existing motion policy without adding another abstraction

Behavior

When motion is allowed, programmatic navigation keeps its existing smooth animation.

When the operating system requests reduced motion, programmatic navigation moves without animation.

E2E fixture captures also move without animation, which preserves deterministic screenshots and interaction timing.

This PR does not change touchpad inertia, mouse-wheel scrolling, scrollbar dragging, or other user-driven scrolling.

Verification

• npm --workspace @maka/ui run typecheck — passed
• npm --workspace @maka/desktop run typecheck — passed
• npm --workspace @maka/desktop test -- --test-name-pattern="single live-turn handoff" — 1,095 passed
• Biome check on all changed files — passed
• git diff --check origin/main...HEAD — passed
• Manual verification — passed

中文

概要

Maka 已有统一的 Desktop 程序化滚动策略。该策略遵守操作系统的 reduced-motion 偏好，并在确定性 E2E 截图期间关闭动画。

部分导航路径绕过了这项策略，直接使用硬编码的 smooth，或者在未指定行为时默认使用 smooth。

因此，即使用户已要求减少动态效果，以下交互仍可能播放平滑滚动动画：

• 跳转到会话中的搜索结果
• 使用 prompt 锚点栏导航
• 展开并定位渐进挂载窗口之外的 turn
• 在记忆文档编辑器中定位条目

本 PR 让这些交互复用现有滚动策略，使程序化滚动在整个应用中遵守一致的原生桌面交互规范。

关联 #2084

根因

主会话已经将 readScrollMotionBehavior() 传给 ChatView，但该值没有继续传递到所有内部导航路径。

PromptAnchorRail 和 useProgressiveTurnMount 使用了硬编码的平滑滚动。useChatScroll 也保留了自己的 smooth fallback。

引用侧栏渲染 ChatView 时没有提供这项策略。记忆文档导航则使用了另一处硬编码的平滑滚动。

这些独立默认值使共享策略在实际使用中仍是可选的，也让新增调用方可以无意间绕过它。

变更

• 将 ChatView.scrollBehavior 改为必填，要求每个宿主明确选择滚动行为
• 将选定行为传递给搜索结果导航、prompt 锚点和渐进式 turn 展开
• 在引用侧栏和记忆文档编辑器中使用 readScrollMotionBehavior()
• 删除局部硬编码和 fallback 的平滑滚动
• 复用现有 motion policy，不新增抽象层

行为变化

当系统允许动态效果时，程序化导航继续使用现有的平滑滚动动画。

当操作系统要求减少动态效果时，程序化导航不再播放滚动动画。

E2E fixture 截图也会关闭动画，以保持截图结果和交互时序稳定。

本 PR 不改变触控板惯性、鼠标滚轮、拖动滚动条或其他用户主动滚动行为。

验证

• npm --workspace @maka/ui run typecheck — 通过
• npm --workspace @maka/desktop run typecheck — 通过
• npm --workspace @maka/desktop test -- --test-name-pattern="single live-turn handoff" — 1,095 项通过
• 对所有变更文件运行 Biome check — 通过
• git diff --check origin/main...HEAD — 通过
• 手工验证 — 通过

[Astro-Han]

Approved — I found no reproducible P0–P3 issues at ff3b4673.

This is a well-sized fix for the underlying problem. The reduced-motion policy already existed and was the correct authority, but ChatView still made that decision optional, allowing deeper navigation paths to fall back to their own smooth behavior. Making scrollBehavior required and threading it through the existing component seams turns that policy into an explicit contract without introducing parallel state or another abstraction.

Although the diff touches ten files, the semantic change remains small: most edits are necessary consumer updates caused by making the contract required. The remaining production scroll sites now use the shared policy, CI is green, and the PR is cleanly mergeable.

One non-blocking suggestion: a focused behavior test proving that auto reaches prompt-anchor navigation and progressive turn reveal would make the regression boundary more durable. The changed tests currently mostly satisfy the newly required prop. Given the bounded implementation and the recorded manual verification, I do not consider that a blocker.

中文对照

批准——在当前 head ff3b4673 上没有发现可复现的 P0–P3 问题。

这个修复的规模与问题匹配。reduced-motion 策略原本已经存在，也是正确的权威来源；真正的问题是 ChatView 仍把这个决定作为可选项，使更深层的导航路径可以退回各自的 smooth 行为。将 scrollBehavior 改为必填，并沿现有组件边界传递，把策略变成了明确契约，没有引入平行状态或新的抽象层。

虽然 diff 涉及十个文件，但语义改动仍然很小：大部分修改只是必填契约带来的必要调用方更新。其余生产滚动路径现在均使用共享策略，CI 全绿，PR 也可以干净合并。

一个非阻塞建议：可以增加一条聚焦的行为测试，证明 auto 确实传递到了 prompt 锚点导航和渐进式 turn 展开。当前改动中的测试主要是在适配新的必填参数。不过考虑到实现范围有界，并且作者记录了手工验证，我不认为这需要阻止合并。

Disclosure: Codex assisted by inspecting the full diff, caller paths, remaining programmatic-scroll sites, and CI evidence. Astro-Han reviewed the resulting evidence, determined the finding threshold, and made the final approval decision.