feat(tui): add purple shimmer for capability keywords

[Luxincess]

Problem

OpenPI currently highlights capability intent keywords with a static purple
foreground color. The visual feedback is easy to miss and does not provide the
flowing purple shimmer effect used by Claude Code for ultracode.
Issue : #301

Value

Improve the visual feedback for capability intent keywords while keeping the
existing capability recognition and execution behavior unchanged.

Approach

• Add a flowing purple shimmer effect for subagent, subagents, workflow,
  and workflows.
• Use per-character purple intensity changes to create the moving highlight.
• Keep a 256-color fallback for terminals without truecolor support.
• Refresh the TUI at a bounded interval while an applicable capability intent
  is present.
• Clean up the animation timer when the Session shuts down.
• Keep the existing capability intent classifier as the source of truth.
• Do not modify input text, cursor behavior, Session history, model context,
  capability loading, or permissions.

Validation

• bun run check passed
• bun run test see fix(repo): enforce LF checkouts across platforms #302
• node --test --experimental-strip-types tests/extensions/capabilities/ui.test.ts
  • Passed: 5/5 tests.
• Manually verified the effect in the real Pi TUI.

Impact

• User-visible behavior: capability keywords now use an animated purple
  shimmer instead of a static color.
• Model-visible context/tools: None.
• Runtime/lifecycle: The render timer is cleaned up on Session shutdown.
• Persisted config/data: None.
• Compatibility: 256-color terminals use a purple fallback.

Closes : #301

[tt-a1i]

审查结论：Changes Requested

审查固定版本：665e1954475dac35c6bed125854145d78ff25daa。

解决什么问题 / 价值 / 方法

把 subagent(s)、workflow(s) 的静态紫色高亮改成逐字符流光，让输入中的能力识别反馈更明显。实现复用了现有 CapabilityIntentHighlightEditor 和 editor layer，使用 1.4 秒动画周期、120ms 刷新间隔；没有新增命令、配置或编辑器框架，也没有改动输入正文、能力分类、工具权限或模型上下文。

Findings

• Standards：未发现确认的架构或生命周期违规。
• Spec：1 项 P2，详见行内评论。#301 要求不支持动态效果时退回静态紫色，但目前 truecolor 和 256-color 两条路径都随 phase 变化，没有静态降级路径。这里不是认为所有 256-color 终端都不能播放动画。

建议只补齐这个小边界和回归测试，不必增加设置或通用动画框架。

验证证据

此前在上述 exact head 的隔离 checkout 上完成：

• bun run check：通过。
• bun run test：Node 1071 通过、1 项平台跳过、0 失败；Vitest 30 通过。
• capabilities index/UI 专项测试：20/20 通过。
• git diff --check：通过。
• 对实际颜色函数的探针：四个关键词在两种颜色模式下都会随 phase 改变；去除 ANSI 后文本和原生 Pi visibleWidth 保持不变。
• 对实际扩展配合模拟 host/timer 的探针：重复包装没有新增计时器，session shutdown 清理计时器，空输入不请求重绘，关键词输入会请求重绘。空输入仍有周期性读取/分类；这不是零 CPU 开销的证明。

GitHub 已有 CI 为绿色，但 PR 当前落后于 main；同步后仍需验证最终 head。

证据边界

上述是源码、自动化和模拟宿主验证，不是真实 TUI 验收。真实终端中的光标、换行及浅色主题可读性仍未由本次审查验证，不能用 CI 或模拟探针代替。没有把这些未知项报成已确认缺陷。

本次仅提交 review，没有修改代码或合并。

[tt-a1i]

⚠️ [P2] 补齐 Issue #301 要求的静态紫色降级路径

#301 明确要求“不支持动态效果的终端能够正常显示静态紫色”。这里的 truecolor 与 256-color 分支都使用随 phase 变化的 intensity；index.ts 也无条件传入动态 phase，并在存在关键词时每 120ms 请求刷新，因此目前没有实现该静态降级行为。实际调用探针也确认了四个关键词在两种色彩模式下 phase=0 与 0.5 的输出均不同。

这不是说 256-color 终端一定不能动画，而是颜色模式切换本身不能实现约定的静态降级。请用最小改动保留静态紫色路径，并让进入降级路径时不再触发动画刷新；补充该路径输出不随 phase 变化、不会继续动画重绘的测试即可，不需要额外配置或动画框架。

[tt-a1i]

Code Review Summary

结论：Changes Requested（1 项 P2） — 审查版本 665e195。

完整 review 与行内反馈。

• 需要补齐 feat(tui): add Claude-style purple shimmer for capability keywords #301 约定的静态紫色降级：当前两种颜色模式都会动画，缺少降级后稳定显示且不继续动画刷新的路径。建议最小修复，不新增设置或框架。
• 现有 editor layer 复用、计时器清理及能力/权限边界未发现确认问题。
• exact-head 本地 check 通过；Node 1071 通过 / 1 平台跳过，Vitest 30 通过，专项 20/20 通过。
• 真实 TUI 光标、换行和浅色主题可读性仍未由本次审查验收；模拟探针和绿色 CI 不代表这些已通过。PR 当前落后 main，同步后需重新验证最终版本。

本次只提交审查，未改代码、未合并。