fix(groups): correct rename-sync event name and unreliable getMeta path

The previous fix listened for a documented-but-wrong event name
(group.profile.updated); live instrumentation of a real rename showed
the actual wire event is group.settings.updated. Fixing only the name
still didn't work: the refresh mechanism it triggered
(getMeta(startMetaQuery().withDesc().build())) was itself unreliable
against this backend -- live-confirmed to either time out (504) on a
brand-new topic or return stale pre-rename data on an established one,
which also explains the "second rename flips back to the original
name" symptom (a late, stale response from an earlier call clobbering
the correct value).

Replace it with the already-reliable REST getGroup() response applied
locally via the SDK's own _processMetaDesc (same internal method the
SDK calls when a real meta response arrives; confirmed to reach
me.contacts(), which the sidebar/header read).

Also fixes a second, independently-discovered bug found while
verifying the above: notifyTopic's requestAnimationFrame-based
notification batching could get permanently stuck if the callback
was scheduled while the page wasn't compositing frames, silently
freezing all future topic-list updates (not just renames) until a
full reload. Falls back to setTimeout when the document is hidden,
since that is never dropped the way the rAF was.

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

web/src/features/groups/GroupDetailColumn.tsx

@@ -172,10 +172,13 @@ export function GroupDetailColumn({ topicId, peerName, onClose, onOpenHistory }:
       queryClient.setQueryData(['group', topicId], (prev: GroupProfile | undefined) => (prev ? { ...prev, ...data } : data));
       setNameEditing(false);
       // The renamer's OWN sidebar/header (`contact.public?.fn`, native SDK state) doesn't update from
-      // this REST call either -- only from the `group.profile.updated` push topics.ts now listens for,
-      // which this account won't receive for its own action. Trigger the same SDK-sanctioned refresh
-      // directly instead of waiting on an unconfirmed self-echo of that push.
-      tinode.getTopic(topicId).getMeta(tinode.getTopic(topicId).startMetaQuery().withDesc().build()).catch(() => {});
+      // this REST call either -- only from the `group.settings.updated` push topics.ts listens for,
+      // which this account won't receive for its own action. `data` here is already the fresh REST
+      // response, so apply it locally via `_processMetaDesc` (live-confirmed to reach `me.contacts()`,
+      // see topics.ts's comment on the same call) instead of an extra `getMeta(...withDesc())` round
+      // trip -- that SDK-sanctioned path was live-instrumented and found to reliably time out (504) or
+      // return stale data against this backend, so it's not used anywhere in this fix anymore.
+      tinode.getTopic(topicId)._processMetaDesc({ public: { fn: data.name, name: data.name } });
     },
     onError: (err) => showError(err, '群名保存失败'),
   });