修复刷新/深链进入已解散的群聊时显示错乱，改成直接跳回消息列表

用户实机截图报告：一个群被解散后，如果直接刷新页面（或深链）停留在这个群的
URL上，标题栏/侧边栏显示原始topic id（不是群名）、"1970/1/1"的时间戳、
"0人"成员数，而不是跳转离开。

这跟已有的"正在查看时被实时解散"处理（subscribeTopicGone/onDeleteTopic）
不是同一条路径——那个只覆盖"已经订阅成功、活跃看着的时候被解散"，覆盖不了
"这次页面加载压根没订阅成功过"的情况。实机复现确认：openConversation()对
一个已解散群的{sub}请求会正确收到404 CommError拒绝，但ConversationView
原来的catch只弹一个通用的"加载会话失败，请重试"提示，不会跳转，会话视图就
停留在一个半初始化的空壳状态。

修复：新增isTopicGone()识别这个404，命中后跟"实时解散"走一样的用户体验
（toast提示+跳转回/messages）。同时发现并修复了一个连带的清理问题——单纯
调用getTinode().getTopic(name)（openConversation内部一开始就会调，不管
后面订阅成不成功）就已经在SDK本地缓存里留下一个空壳对象，光是这个空壳存在
就足以让侧边栏显示出这条错乱的记录；而清理这个空壳时又跟ConversationView
自己卸载时的closeConversation()清理逻辑（它自己也会重新调用getTopic()）
产生竞态——直接删除后又被重新创建。改成维护一个"确认已消失"的名单，让聊天
列表的过滤逻辑直接按名字永久排除，不再依赖谁先执行、谁后执行。

实机验证：真实解散一个群后，直接deep-link/刷新回这个群的URL——确认页面
立即跳转回/messages，且侧边栏不再出现这条已解散群的残留记录。

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

web/src/features/messages/ConversationView.tsx

@@ -27,11 +27,13 @@ import { isRecalled } from '@/lib/messages/dispatch';
 import { renderDrafty } from '@/lib/messages/drafty';
 import { buildMentionedContent, detectMentionTrigger, type PendingMention } from '@/lib/messages/mentions';
 import { sendFile, sendImage, sendVoice } from '@/lib/tinode/attachments';
+import { isTopicGone } from '@/lib/tinode/errors';
 import { useChatList, useTinode, useTopicMessages } from '@/lib/tinode/hooks';
 import { forwardMessage, sendPrebuiltContent, sendReply, sendText } from '@/lib/tinode/send';
 import {
   closeConversation,
   ensureTopicAttached,
+  forgetTopic,
   markConfirmedRead,
   openConversation,
   setActiveConversationTopic,
@@ -260,7 +262,26 @@ export function ConversationView() {
           me.getMeta(me.startMetaQuery().withOneSub(undefined, topic.name).build()).catch(() => {});
         }
       })
-      .catch((err) => showError(err, '加载会话失败，请重试'));
+      .catch((err) => {
+        // A group dissolved before this specific page load ever subscribed to it -- distinct from
+        // subscribeTopicGone below, which only covers watching it get dissolved live while already
+        // subscribed. See isTopicGone's own comment for the real, reported bug this closes (a
+        // deep-link/refresh into an already-dissolved group left the screen sitting on a raw-topic-id,
+        // "1970/1/1", "0 members" stub instead of leaving). Same user-facing outcome as the live case
+        // (toast + bounce to the chat list) for consistency, not a special "this group doesn't exist"
+        // message -- from this user's vantage point both cases are just "this group is gone now".
+        if (isTopicGone(err)) {
+          // The failed subscribe attempt above already left a bare, empty stub for this topic in the
+          // SDK's cache (getTopic() creates one just by being called, before it knows whether the
+          // subscribe will succeed) -- without this, that stub alone is enough to make the chat list
+          // keep showing this now-gone group as a broken-looking row even after navigating away.
+          forgetTopic(topicId);
+          notify('该群聊已解散');
+          navigate('/messages', { replace: true });
+          return;
+        }
+        showError(err, '加载会话失败，请重试');
+      });
     return () => {
       closeConversation(topicId).catch(() => {});
     };