第三轮深度测试：修复7个并行agent发现的前端问题，含REASON_MESSAGES系统性补全

派了Ch1-2/3-4/5-6/7/8/9/10-11共7个agent对全部11章重新深度测试。后端问题已核实追加进
docs/IM-后端问题清单-2026-09-04.md（新增6-9条，发给用户）；本次是前端问题的修复。

**REASON_MESSAGES系统性补全（最高优先级，多个agent独立发现同一个缺口）**
im-api.js的REASON_MESSAGES表新增22个条目，最重要的是PERMISSION_DENIED——后端
server/im_http.go里403响应统一用这个reason（30余处调用），但表里原来只有一个从未
被后端实际发送过的死条目FORBIDDEN，导致全站几乎每一个403从工程一开始就在展示原始
英文"permission denied"。一并补上VERSION_CONFLICT/MALFORMED_REQUEST（Ch9 agent实测
命中）、NOT_FOUND、VERIFICATION_RATE_LIMITED（动态文案，同TOO_MANY_ATTEMPTS模式）等。
新增translateReason()导出函数并用于send-message.jsx的sendFavorite——favorites/forward
等几个批量接口恒定200、真实成败包在items[].reason里，imRequest的自动翻译够不到这种
per-item场景，之前直接显示原始reason字符串。tinode-web.jsx同理补了CTRL_ERROR_TEXT_CN
（原生WS {ctrl}协议错误，同样绕开REASON_MESSAGES）并修了原表从未真正匹配过的bug——
CommError会把状态码拼进message变成"authentication failed (401)"，原表按裸文本精确
匹配，看着正常纯粹是因为401/403兜底文案凑巧一样，一旦命中"unknown authentication
scheme"这类会被兜底文案误导、"policy violation"这类会直接漏出英文。uploadLargeFile/
createChatUploader/createFileDownloader同样绕开REASON_MESSAGES（走原生{ctrl}协议），
补了UPLOAD_CTRL_TEXT_CN小词典。已用真实账号端到端验证：favorites/forward到P2P目标
触发的PERMISSION_DENIED现在正确显示"没有权限执行此操作"；draft接口版本冲突正确显示
"内容已被修改，请刷新后重试"。

**编辑消息时打开附件面板会静默覆盖被编辑消息（Ch3-4 agent发现，数据损坏级别）**
sendMessage对editing状态一律用head.replace，但onAttachFile/onAttachImage/onAttachAudio
原来只在forwardMessage时置空，编辑态没有同款门禁——编辑一条消息不改文字、点"+"选张图片
或名片，会直接把附件内容替换掉被编辑消息的原文，无任何确认。messages-view.jsx新增
editingMessage门禁，和forwardMessage一样把三个attach回调置空（等价于隐藏整个"+"按钮）。
已用真实浏览器验证：编辑态下"+"按钮消失，取消编辑后正常恢复。

**草稿防抖单一共享定时器丢字（Ch1-2、Ch3-4两个agent独立发现）**
handleComposerChange用单个this.draftSaveTimer，话题A打字触发600ms保存后300ms内切到
话题B，会把A的定时器clearTimeout掉，那次输入永久丢失；version也在定时器触发时才重新
读state，此时可能已经在别的话题上，退化成硬编码0——叠加后端draft接口对version=0"无条件
跳过乐观锁"的行为（已记入后端清单新增6），可能静默覆盖别的标签页写入的更新草稿。改为
按话题分开的定时器map，version在调用的当下（保证仍在该话题）同步捕获进闭包。

**呼叫状态机两处真实bug（Ch8 agent此前发现，本次重新核实live代码后确认+修复）**
1. 通话中导航离开messages-view.jsx整个组件树（切到工作台/个人设置，或移动端切回会话
   列表）时，没有任何hangup清理——componentSetup已有的"切换话题时正确挂断"逻辑只在
   componentDidUpdate里，组件真正卸载时不会触发。CallPanel自己的componentWillUnmount
   只做本地清理，不通知对方也不重置tinode-web.jsx顶层callState，导致下次切回通话话题
   时remount出一个callState卡在CALL_STATE_IN_PROGRESS的"僵尸"面板——start()走"我们刚
   接听"分支直接return，从不调getUserMedia，本地媒体永久拿不到。补了对称的
   componentWillUnmount挂断逻辑。
2. this.callTimeoutTimer声明后从未被真正setTimeout赋值——呼出无人接听或accept信令
   （fire-and-forget的{note}包）被丢会永久卡在"呼叫中"。补了armCallRingTimeout()，
   60秒未接通按跟手动取消完全一样的路径挂断（不发明新的通话结果语义），在收到对方
   accept信号的两处分支都正确清timer。

**其余前端修复（按文件）**
- messages-view.jsx: @提醒mentionedUsers只在切话题时清空，同一话题内后续消息里字面
  文本"@张三"会被静默解析成真实提醒（发送后清空）；jumpToMessage点开已撤回/删除的
  搜索结果原来只console.error静默失败，补了用户可见的错误提示；批量收藏对
  favorites/batch共享Idempotency-Key导致的静默丢失（已知后端问题）不再照单全收
  "收藏成功"，改为发送后重新拉取真实收藏列表核对每条是否真的落地。
- audio-recorder.jsx: getUserMedia权限弹窗未决出结果时组件被卸载，补_unmounted
  标记避免在死实例上继续跑mediaRecorder.start()。
- send-message.jsx: disabled变为true时（对方拉黑/被禁言等实时ACS变化）没有强制结束
  正在进行的按住录音，可能remount出无用户手势的"自动录音"；mouseup/touchend覆盖不到
  拖出窗口/切换标签页/权限弹窗抢焦点的释放场景，补了blur/visibilitychange兜底。
- tinode-web.jsx: messages-menu视图和messages-home共用MessageCenterView实例无key，
  从messages-home以非整体刷新方式切到messages-menu时菜单打不开，补key={view}。
- message-center-view.jsx: 实名认证驳回提醒的dismiss key只按用户+状态区分，同一状态
  的两次独立驳回会互相误压制，改按submission_id区分。
- contact-management-view.jsx: Profile/Settings靠getUserProfile刷新拉黑状态，但该
  接口对被拉黑对象直接403，导致"之前会话就已拉黑"的场景完全感知不到——叠加
  getConversationContext兜底（该接口对拉黑目标正确返回200+relationship）。
- group-management-view.jsx: AdminList显示群主/管理员姓名漏了group_nickname兜底；
  JoinRequests从聊天页横幅进入时返回按钮硬编码回group-settings（应回聊天本身），
  从Governance进入时返回group-settings而非group-governance（与AdminList/Muted不一致）。
- workplace-collaboration-view.jsx: OrganizationDirectory/DeptNode的部门树加载失败
  被无条件当成"暂无数据"渲染，补loadError区分+重试链接。
- personal-settings-view.jsx: CacheClear对navigator.storage/caches整个不存在的情况
  只有react出了范围的.catch()覆盖不到的同步抛错，加了特性检测+try/catch；
  YouthModeVerify触发TOO_MANY_ATTEMPTS锁定后确定按钮没有禁用/倒计时，会继续发出
  注定失败的请求。
- security-support-view.jsx: 意见反馈category字段在config未加载完成前可为空但没有
  提交前校验，会打到后端400。
- use-cached-data.js: bootstrap等首次拉取失败且无缓存兜底时永久停在undefined，加了
  一次3秒后重试（仅在完全没有缓存值时触发，已有缓存值维持原"显示旧数据"行为不变）。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

src/views/tinode-web.jsx

@@ -160,20 +160,42 @@ const AUTH_FLOW_VIEWS = ['tenant', 'login', 'register', 'reset', 'cred',
 // ctrl.params 里也没有像 REST 层那样稳定的 reason 字段可用（已实测确认）。
 // 原来这里直接把 err.message 原样显示，登录密码打错用户看到的是英文 "authentication failed"，
 // 不是参考图要求的"账号或密码错误"。
-const LOGIN_ERROR_TEXT_CN = {
+//
+// 这张表原来按 err.message 精确匹配裸文案——但 tinode-sdk 的 CommError 构造时会把状态码拼进
+// message 里（"authentication failed (401)"），导致这张表实际上从未真正命中过：'authentication
+// failed' 之所以看起来工作正常，纯粹是因为紧接着的 401/403 兜底分支凑巧给出了同一句译文，掩盖
+// 了匹配从未成立这件事；一旦命中 'unknown authentication scheme'（401，跟密码错误共用同一个状态
+// 码，会被兜底分支误判成"账号或密码错误"）或 'policy violation'（422，不在兜底范围内）这两种更
+//少见的场景，用户就会看到带着 "(状态码)" 尾巴的原始英文。translateCtrlError 先去掉这段状态码
+// 后缀再查表，两个问题一并解决。
+//
+// 同一张表也被 handleDisconnect 复用，用来翻译 {hi} 阶段（登录请求发出之前）的连接失败——那个
+// 场景下 permission denied 最常见的真实原因是租户被停用，不是"账号或密码错误"，所以只在这里放
+// 一份不带 401/403 兜底的裸翻译（loginErrorMessage 自己的兜底只应用在真正的登录尝试上）。
+const CTRL_ERROR_TEXT_CN = {
   'authentication failed': '账号或密码错误',
   'authentication required': '请先登录',
   'unknown authentication scheme': '登录方式不受支持，请刷新页面重试',
-  'policy violation': '当前操作不符合安全策略要求'
+  'policy violation': '当前操作不符合安全策略要求',
+  'permission denied': '没有权限执行此操作，请重新登录'
 };
+function translateCtrlError(err) {
+  const raw = err && err.message;
+  if (!raw) return null;
+  const normalized = raw.replace(/\s*\(\d+\)\s*$/, '').trim().toLowerCase();
+  return CTRL_ERROR_TEXT_CN[normalized] || null;
+}
 function loginErrorMessage(err) {
-  const known = err && err.message && LOGIN_ERROR_TEXT_CN[err.message.trim().toLowerCase()];
+  const known = translateCtrlError(err);
   if (known) return known;
   // 未知文案时按状态码兜底，401/403 绝大多数场景就是账号或密码错误
   if (err && (err.code === 401 || err.code === 403)) return '账号或密码错误';
   return (err && err.message) || '登录失败，请重试';
 }
 
+// See armCallRingTimeout below.
+const CALL_RING_TIMEOUT_MS = 60000;
+
 class TinodeWeb extends React.Component {
   constructor(props) {
     super(props);
@@ -908,13 +930,17 @@ class TinodeWeb extends React.Component {
     }, 1000);
   }
 
-  // Connection lost
+  // Connection lost. Also covers a {hi} handshake rejected before login ever gets a chance to run
+  // (e.g. the tenant being deactivated mid-session) -- that path calls onDisconnect, not the {login}
+  // catch block down in doLogin, so without translateCtrlError here it showed the raw English
+  // ctrl.text (e.g. "permission denied (403)") instead of any Chinese message at all.
   handleDisconnect(err) {
+    const known = translateCtrlError(err);
     this.setState({
       connected: false,
       ready: false,
       topicSelectedOnline: false,
-      errorText: err && err.message ? err.message : "Disconnected",
+      errorText: known || (err && err.message ? err.message : "Disconnected"),
       errorLevel: err && err.message ? 'err' : 'warn',
       loginDisabled: false,
       contextMenuVisible: false,
@@ -2329,6 +2355,7 @@ class TinodeWeb extends React.Component {
   }
 
   handleStartVideoCall() {
+    this.armCallRingTimeout();
     this.setState({
       callTopic: this.state.topicSelected,
       callState: CALL_STATE_OUTGOING_INITATED,
@@ -2337,6 +2364,7 @@ class TinodeWeb extends React.Component {
   }
 
   handleStartAudioCall() {
+    this.armCallRingTimeout();
     this.setState({
       callTopic: this.state.topicSelected,
       callState: CALL_STATE_OUTGOING_INITATED,
@@ -2344,6 +2372,28 @@ class TinodeWeb extends React.Component {
     });
   }
 
+  // this.callTimeoutTimer was declared (and already read/cleared in handleCallClose) but never
+  // actually assigned anywhere -- an outgoing call the other side never answers (or whose 'accept'
+  // {note} gets silently dropped, since every call-signaling step after the initial invite is a
+  // fire-and-forget {note}, not a {pub} with a server ack) left the caller's UI stuck on "呼叫中"
+  // forever, with manual hang-up the only way out. This arms a plain no-answer timeout for the
+  // outgoing-ring wait only, mirroring a normal phone call -- it reuses the exact same hang-up path
+  // as clicking the cancel button by hand (real 'hang-up' note to the peer + the usual top-level
+  // state reset), so it doesn't invent any new call-outcome semantics. Deliberately scoped to just
+  // this one wait state: adding similar timeouts around mid-call offer/ice-candidate/answer signaling
+  // would risk false-positive hangups on connections that are just slow, not actually dropped.
+  armCallRingTimeout() {
+    clearTimeout(this.callTimeoutTimer);
+    this.callTimeoutTimer = setTimeout(() => {
+      this.callTimeoutTimer = null;
+      if (this.state.callState != CALL_STATE_OUTGOING_INITATED) {
+        return;
+      }
+      this.handleCallHangup(this.state.callTopic, this.state.callSeq);
+      this.handleCallClose();
+    }, CALL_RING_TIMEOUT_MS);
+  }
+
   handleCallInvite(callTopic, callSeq, callState, audioOnly) {
     switch (callState) {
       case CALL_STATE_OUTGOING_INITATED:
@@ -2435,6 +2485,7 @@ class TinodeWeb extends React.Component {
   }
 
   handleCallAccept(topicName, setCallTopic, callSeq) {
+    clearTimeout(this.callTimeoutTimer);
     const topic = this.tinode.getTopic(topicName);
     if (!topic) {
       return;
@@ -2463,6 +2514,9 @@ class TinodeWeb extends React.Component {
     }
     switch (info.event) {
       case 'accept':
+        // Either branch below means the outgoing ring wait is over one way or another --
+        // see armCallRingTimeout.
+        clearTimeout(this.callTimeoutTimer);
         // If another my session has accepted the call.
         if (Tinode.isMeTopicName(info.topic) && this.tinode.isMe(info.from)) {
           this.setState({