[Feature]: 手动压缩上下文的按钮入口（输入框工具栏 / 上下文用量面板） #3862

Problem / opportunity

手动压缩上下文（compaction）目前只有一个入口：在输入框里手打 /compact 并回车。

问题不在能力，在可发现性：

• 输入框底部工具栏右侧的上下文用量圆环（tooltip 形如 0/1M 0%），点开是上下文构成面板，里面只有「查看报告 / 折叠」，没有任何压缩入口；
• 唯一能看到「压缩上下文」按钮的地方，是上下文已经溢出之后的错误提示卡片 —— 也就是最晚的时刻；
• 结果是：用户往往在会话已经跑偏（回答变飘、反复调同一个工具）之后，才知道原来可以手动压一次。

Proposed behavior

在上下文用量这一处补一颗「手动压缩」，行为与 /compact 完全等价：

1. 位置：输入框底部工具栏、上下文用量圆环的左侧；窗口较窄时改为并入圆环打开的 popover 底部，避免挤占权限胶囊。
2. 文案：内向箭头图标 + 「压缩」，title / aria-label 为「压缩上下文（/compact）」。
3. 点击后：走现有的 compactSession 通道，复用已有的「正在压缩上下文」状态与压缩卡片，不新增后端能力。
4. 状态：会话运行中按钮置灰并提示「请等待当前会话结束后再压缩」；压缩进行中再次点击提示「压缩仍在进行中」；无会话时提示「当前没有可压缩的会话」—— 也就是把现有的四类提示文案接到这个按钮上，不要静默失败。
5. 安全：输入框里有用户草稿时，不要清空或覆盖用户已输入的内容。

Product surface

Desktop app

Details, examples, or constraints

• 现状参考（前端）：/compact 已经完整可用，四类边界情况都有现成文案（无会话 / 会话忙 / 压缩进行中 / 用法错误）。本需求不需要新后端，只是把已有命令暴露为一个可点击的入口。
• 参考样式：其他 agent 在上下文统计面板底部放了一颗「手动压缩」按钮（图标 + 文案，浅色胶囊），点击即触发压缩。这类入口比斜杠命令更符合"用量看得见"的心智。
• 与自动压缩的关系：不改变任何自动压缩阈值或策略，只提供一个用户可主动选择的时机。
• 与 [Feature]: 对于compact 时机和压缩上下文组成的调研 #3829 的关系：[Feature]: 对于compact 时机和压缩上下文组成的调研 #3829 讨论的是压缩的质量与时机（摘要可信度、失败重试、按轮折叠）；本 issue 只谈入口可发现性，二者互补，不重复。
• 验收标准：
  • 工具栏（或 popover 底部）出现「压缩上下文」入口，中文界面下为中文文案；
  • 点击等同于 /compact，不额外产生模型请求；
  • 会话运行中 / 压缩中 / 无会话三种情况都有明确提示；
  • 可键盘聚焦，带 aria-label 与 hover 提示；暗色与亮色主题下都可读。

补充（与本次需求无关，供参考，可另开 issue）：我尝试用官方 Creative mode 的 UI 定制（FrontendWorkbench）自己加这颗按钮，代码已完成，但 apply 阶段候选前端在 15 秒内没有回报 ready，稳定得到 candidate_ready_timeout（OpenBitFun 1.0.10 / Windows 11；已排除窗口最小化、页面遮挡、脚本异常 —— 换成一行的空实现同样复现，重启客户端后仍然复现）。如果这条链路本身有问题，我可以按需补日志与复现步骤。