修复Zentao批量报告的6个前端bug：来电UI不弹出/黑名单发送无提示/群名校验/群人数与通话记录显示uid

用户提供了一份Zentao导出的bug清单（#21/23/24/25/26/27/28共7条），逐条实机复现
排查，修复了其中6个真正的前端bug，1个是纯后端问题（禁言不生效）已记录到
docs/IM-后端问题清单.md，1个（好友申请404/500）未能独立复现只记录了测试团队
的原始报告，另1个（离线状态推送）实测后确认并非报告描述的"永久不更新"，只是
有正常的心跳超时延迟。

- **#23 来电UI完全不弹出**（根因最深的一个）：initCallSignaling用的是
  `me.getMeTopic().contacts()`枚举联系人再查最新消息——但这个方法只反映`me`
  话题自己的订阅同步进度，一个P2P话题可能早就真正订阅上、能收到消息，`me`的
  同步却还没跟上，导致这个联系人在枚举里直接消失。用两个真实账号实机验证：
  被叫方`me.contacts()`只枚举出1个群，主叫方完全没出现，来电消息静默丢失。
  topics.ts里`getChatListSnapshot()`自己的注释早就写明了这个坑、并且已经改
  用`mapTopics()`规避，只是`stores/calls.ts`这个监听器当时没有跟着改。现在
  统一复用`getChatListSnapshot()`，实机验证来电卡片正确弹出。

- **#28 拉黑后发送消息无原因提示**：读tinode-sdk源码确认发送失败的具体原因
  从架构上就拿不到——`Topic#publishMessage`自己的`.catch()`把服务端拒绝原因
  吞掉、只留一个`_failed`标记，不会重新抛出。改成事前判断：新增
  `getConversationContext()`（P2P专用，`relationship`字段区分
  `blocked_by_me`/`blocked_by_peer`），发送区直接换成对应文案的横幅，两个
  方向都拿真实账号互相拉黑验证过。

- **#26 群名超长/留空自动名两个校验问题**：`MAX_TITLE_LENGTH`一直是60，但
  后端`im_http.go`真实校验的是32字（读源码确认），导致33-59字之间的群名能
  输入、能提交，然后被后端拒绝只显示通用错误。改成32，从输入框这一层就不
  再放行超长名。另外群名留空时自动拼接的成员昵称组合，理论上可能被内容审核
  拒绝——这种情况下用户根本不知道"名字"是问题所在，补了针对性提示。

- **#27 通话记录/群列表显示原始uid、群人数显示0人**（2处独立bug）：
  1. `CallHistoryView.tsx`按`peer_user_id`（真实usr id）去匹配聊天列表的
     `contact.topic`（建立过真实会话后已经是服务端重命名过的p2p哈希），两个
     不是同一个id空间，永远匹配不上，一直显示原始id。改成用`item.topic`
     （已确认和chatlist的topic是同一个值）去匹配。
  2. 实测发现`GET /groups`列表接口的`member_count`会返回0，但同一个群
     `GET /groups/{topic}`单独查询正确返回4——两个接口的计数器不一致（后端
     已知问题，见问题8），前端这次统一改成"读到0就不显示人数"而不是显示一
     个已确认错误的数字。

以上改动均跑过`tsc -b --noEmit`/`oxlint`/`vite build`，除#26外全部用两个真实
账号（systest02/systest04）互相操作实机验证。

web/src/stores/calls.ts

@@ -10,7 +10,7 @@ import {
 } from '@/lib/calls/agora-client';
 import { callContentOf, callStateOf, sendCallAccept, sendCallHangup, sendCallInvite, sendCallRinging, type CallWebrtcState } from '@/lib/tinode/calls';
 import { getTinode } from '@/lib/tinode/connection';
-import { getMessagesSnapshot, subscribeAnyTopicChange, subscribeTopicInfo } from '@/lib/tinode/topics';
+import { getChatListSnapshot, getMessagesSnapshot, subscribeAnyTopicChange, subscribeTopicInfo } from '@/lib/tinode/topics';
 import { useSessionStore } from '@/stores/session';
 
 export type CallPhase = 'idle' | 'outgoing' | 'incoming' | 'connected' | 'ended';
@@ -243,12 +243,21 @@ export function initCallSignaling() {
   subscribeAnyTopicChange(() => {
     const myUserId = useSessionStore.getState().myUserId;
     if (!myUserId) return;
+    // NOT `getTinode().getMeTopic().contacts()` -- live-confirmed real bug this fixes (user-reported:
+    // a whole incoming-call test milestone blocked, WS packet capture confirmed the invite genuinely
+    // arrives, but no incoming-call UI ever appeared): `contacts()` reads the `me` topic's OWN
+    // internally-tracked subscription list, populated only once `me`'s `{meta sub}` sync reports this
+    // specific contact -- but a P2P topic can be fully subscribed and sitting in the SDK's topic cache
+    // (able to receive and store a real incoming call invite) well before that sync catches up. This
+    // exact gap is already documented on `getChatListSnapshot`'s own comment (topics.ts) as the reason
+    // that function uses `mapTopics` instead -- this call-signaling listener just never got the same
+    // fix when it was written. Confirmed live: a real two-account call, `me.contacts()` on the callee's
+    // own live session enumerated ONE contact (a group) and silently omitted the caller entirely, while
+    // `getChatListSnapshot()`'s own list correctly showed both.
     const peerNames = new Map<string, string>();
-    getTinode()
-      .getMeTopic()
-      .contacts((c) => {
-        if (c.topic) peerNames.set(c.topic, c.public?.fn || c.topic);
-      });
+    for (const contact of getChatListSnapshot()) {
+      if (contact.topic) peerNames.set(contact.topic, contact.public?.fn || contact.topic);
+    }
 
     for (const topicName of peerNames.keys()) {
       const messages = getMessagesSnapshot(topicName);