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

用户实机截图报告：一个群被解散后，如果直接刷新页面（或深链）停留在这个群的
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/lib/tinode/topics.ts

@@ -122,6 +122,36 @@ export function subscribeTopicGone(callback: (topicName: string) => void): () =>
   return () => goneListeners.delete(callback);
 }
 
+/**
+ * Topics confirmed 404-gone (see forgetTopic below) that `getChatListSnapshot` must never show again
+ * THIS session, no matter what re-creates a cache entry for the name afterward -- live-confirmed real
+ * race: `openConversation`'s own cleanup (`closeConversation`, fired by ConversationView's unmount
+ * effect as the redirect below unmounts it) calls `getTinode().getTopic(topicName)` again for its
+ * `.leave(false)` -- unconditionally, with no way to know this specific name should stay forgotten --
+ * which by itself re-creates a fresh, empty stub the instant `cacheRemTopic` below has removed the old
+ * one, silently undoing the cleanup and leaving the exact same broken sidebar row behind. Excluding by
+ * name in the chat-list filter itself sidesteps that ordering race entirely rather than trying to make
+ * `forgetTopic` run strictly after every other thing that might touch this topic's cache entry.
+ */
+const goneTopicNames = new Set<string>();
+
+/**
+ * For a topic that was never successfully subscribed at all -- e.g. `openConversation()` rejecting
+ * with a 404 (see ConversationView's `isTopicGone` handling) because it was deep-linked/refreshed
+ * into after already being dissolved. Distinct from the live-dissolve path above (`onDeleteTopic`/
+ * `_gone()`, which does its own SDK-side cache cleanup already): merely CALLING `getTopic(name)` --
+ * which `openConversation` always does before it even knows whether the subscribe will succeed --
+ * already leaves a bare, empty stub topic sitting in the SDK's cache, and nothing else ever clears
+ * one that was never truly attached. Left alone, that stub is enough on its own to make the chat list
+ * show a broken-looking row (raw topic id for a name, no `touched`) for a group that, from this
+ * client's perspective, should simply not exist.
+ */
+export function forgetTopic(topicName: string): void {
+  goneTopicNames.add(topicName);
+  getTinode().cacheRemTopic(topicName);
+  notifyTopic(topicName);
+}
+
 function wireTopicCallbacks(topic: Topic) {
   if (wiredTopics.has(topic)) return;
   const notify = () => notifyTopic(topic.name);
@@ -389,7 +419,7 @@ export function getChatListSnapshot(): Contact[] {
   if (chatListSnapshot) return chatListSnapshot;
   const byTopic = new Map<string, Contact>();
   getTinode().mapTopics((topic) => {
-    if (!topic.name || !isChatListTopicName(topic.name)) return;
+    if (!topic.name || !isChatListTopicName(topic.name) || goneTopicNames.has(topic.name)) return;
     prefetchPreview(topic.name);
     // `.topic` (what every consumer of this list actually reads) normally arrives via
     // `_processMetaSubs` merging the server's own `sub.topic` field onto this same cached instance --