fix: realtime friend-request badge via connection-level info fallback

Server friend.request.* signals ride {info} frames addressed to the
recipient's own user id, but the SDK dispatcher resolves that topic via
its topic cache, where the me topic lives under the literal me -- the
lookup missed and the frame was dropped before any listener could see
it, so the 新朋友 badge and NewFriendsView list only updated after a
manual refresh or relogin. topics.ts now forwards frames whose topic is
not in the SDK cache (isTopicCached) through the connection-level
onInfoMessage hook to the same infoListeners used by topic-level
routing (no duplicate delivery), and AppShell invalidates the shared
['friend-requests'] query namespace on friend.request.* events, keeping
the pending badge live on any page. Zentao #3.

web/src/lib/tinode/topics.ts

@@ -128,6 +128,35 @@ export function subscribeTopicInfo(callback: (topicName: string, info: RawTopicI
   return () => infoListeners.delete(callback);
 }
 
+/**
+ * The SDK only routes an incoming {info} packet into Topic._routeInfo (and from there to
+ * topic.onInfo -> the infoListeners fanout above) when the packet's topic name is already in the
+ * client's topic cache -- tinode.dev.js's dispatcher does `#cacheGet('topic', pkt.info.topic)` and
+ * silently drops the frame on a miss. Friend-request signals (Zentao #3) arrive with `topic` set to
+ * the RECIPIENT'S OWN user id (publishIMRelationEvent -> sessionStore.DeliverToUser, i.e. addressed
+ * to the user's `me` topic), but the me topic is cached under the literal "me" -- so that lookup
+ * misses every time and the frame never reached any info listener. Live-confirmed 2026-09-18: the
+ * SDK's own logger showed the raw `friend.request.rejected` frame arriving on the socket while
+ * AppShell's subscribeTopicInfo callback never fired. The connection-level onInfoMessage hook sees
+ * EVERY info packet regardless of cache state, so forward ONLY the frames the topic-level path will
+ * not deliver (isTopicCached false) to the same infoListeners: cached topics keep flowing through
+ * topic.onInfo exactly once (no duplicates), uncached ones stop being silently lost. Both members
+ * are real SDK runtime members absent from the hand-maintained .d.ts (same cast rationale as the
+ * read/unread reads in getChatListSnapshot). Installed from subscribeMeTopic -- the one point every
+ * login flows through -- and re-installed there after resetTinode() rebuilds the instance.
+ */
+function installUncachedInfoFallback(t: unknown) {
+  const sdk = t as {
+    onInfoMessage?: ((info: RawTopicInfo & { topic: string }) => void) | null;
+    isTopicCached?: (topicName: string) => boolean;
+  };
+  sdk.onInfoMessage = (info) => {
+    if (info && sdk.isTopicCached && !sdk.isTopicCached(info.topic)) {
+      infoListeners.forEach((cb) => cb(info.topic, info));
+    }
+  };
+}
+
 const goneListeners = new Set<(topicName: string) => void>();
 
 const newGroupListeners = new Set<(topicName: string) => void>();
@@ -283,7 +312,9 @@ let inFlightMeSubscribe: Promise<unknown> | null = null;
 /** Call once at session start (after login) -- chat-list metadata only, no message bodies. */
 export function subscribeMeTopic(): Promise<unknown> {
   if (inFlightMeSubscribe) return inFlightMeSubscribe;
-  const me = getTinode().getMeTopic();
+  const tinode = getTinode();
+  installUncachedInfoFallback(tinode);
+  const me = tinode.getMeTopic();
   wireTopicCallbacks(me);
   // Read/recv/unread updates (e.g. from noteRead() when opening a conversation) travel through
   // TopicMe's OWN single-slot callback, separate from onData/onInfo/onPres -- wireTopicCallbacks