自动保存缺少明确状态反馈，需核查设置页提交与持久化语义

[qqqqqf-q]

问题

部分设置页面移除手动保存后采用静默自动保存，但用户缺少判断“正在保存、已保存、尚未保存或保存失败”的明确反馈。控件显示新值不等于后端已经持久化；用户无法判断何时可以离开或刷新。

本 issue 单独记录自动保存的反馈与提交语义，不要求立即实施，也不主张给所有页面恢复保存按钮。

已有依据与待确认部分

• feat: autosave settings surfaces, drop manual save buttons #940 将 Bot general、heartbeat、compaction、tool approval 和已有 provider 编辑等设置改为自动保存，其描述明确采用成功静默、失败提示的策略。
• 当前核查源码 apps/web/src/composables/use-autosave-queue.ts（7c97536e4cbb67fbef0805c72513f3ce23458928）内部维护保存队列，但对调用方仅返回 scheduleSync、stop，没有统一可订阅的保存状态。个人资料页也采用成功静默的自动保存。
• 历史反馈（2026-08-20）：配置 Claude Code 第三方接入时，页面没有保存按钮，填写后被理解为已自动保存，但刷新后内容丢失；同时明确提出自动保存应有界面反馈。此项是历史用户报告，尚未在当前版本复现，也尚未确定是保存、缓存、SDK 还是版本差异。
• “多个页面缺少反馈”需要逐页核实，不能把共享队列的行为当成所有页面都相同的证明。

待调查范围

从上述已转换的设置页及 ACP 配置入口开始，逐页记录：保存触发时机（选择、输入、防抖、失焦、确认）、请求中的状态、成功/失败反馈、离开与刷新行为，以及 OSS / Cloud 和部署版本差异。

将两个问题分别验证：

1. 保存成功但用户看不到状态。
2. 实际没有持久化或读回旧值，却让用户误以为保存成功。

预期与验收方向

• 自动保存区域提供轻量且一致的状态反馈，能区分待保存、保存中、已保存和失败；不需要每次成功都弹 toast。
• “已保存”以最新编辑对应的请求成功为依据，不能仅根据本地控件或乐观状态判断；连续修改与请求失败时也不能误报。
• 失败明确提示并提供恢复方式；保留草稿或回滚的行为应清楚。
• 对尚未提交或仍在保存的内容，明确离开/刷新时的处理；对已保存内容不增加多余确认。
• 需要显式提交或有副作用的表单保留清晰的保存入口，避免同一字段出现“确认后还要另存”的歧义。
• 验证慢网、断网、连续修改、立即离开/刷新及重新进入后的读回结果。界面反馈测试与真正持久化测试分开记录。

关联

• feat: autosave settings surfaces, drop manual save buttons #940：自动保存改造背景。
• [Feature]: general页面的那个保存设置给去掉，不需要保存，直接生效 #895：移除手动保存的原始需求。
• 头像修改:弹窗「确认」后仍需再点「保存更改」,双重确认 #1150：头像双重确认是相关的提交语义问题，保留独立跟踪；其截图对应版本仍待定位。
• 与 移动端设置页适配:多层返回头、卡片内边距不一致 #1147、时区默认 UTC,未跟随用户本地时区 #1148、头像链接可填任意 URL,缺少校验 #1149 同批跟进，但本 issue 不混入移动布局、时区默认值或头像 URL 安全修复。