补全群邀请功能的接收方一侧：系统消息里的群邀请通知现在能真正接受

追查"邀请功能不完善"时发现的更大缺口：群邀请在需要审批的情况下（群自身的
进群验证，或被邀请人自己的隐私设置要求验证）不会立即拉人入群，而是创建一条
真正的邀请记录，通过系统消息投递给对方（event_type: group.invitation.created，
action.type: group_invitation_accept，带invitation_id）——但这条系统消息
此前完全没有专门处理，走的是所有group.*事件通用的"查看群聊"跳转逻辑，直接
导航到一个对方根本还不是成员的会话，大概率打不开。

协议文档把POST /v1/im/group-invitations/{id}/accept标成"待实现"，和今天
早些时候发现的草稿持久化接口是同一种文档滞后于后端实际进度的情况——读了
im_be的serveIMGroupInvitationResource源码确认这个接口真实可用。

actionRoute()现在对这个特定事件类型不再返回通用的导航链接，卡片里改成渲染
一个真正的"接受邀请"按钮（阻止事件冒泡，避免和卡片自身的整体点击-标记已读
逻辑冲突），点击后调用accept接口，成功直接跳转到这个群（这时候已经是成员
了），失败在卡片上原地显示失败原因。

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

web/src/lib/api/groups.ts

@@ -300,13 +300,43 @@ export function updateGroupGovernance(
   return imPatch<GroupGovernance>(`/groups/${encodeURIComponent(topic)}/governance`, patch);
 }
 
+/**
+ * Per-invitee outcome, confirmed by reading im_be's serveIMGroupInvitations directly (not just the
+ * doc's own single-outcome worked example): `"joined"` when the group's own governance AND the
+ * target's own privacy setting both don't require approval (added immediately, no further action
+ * needed); `"already_member"`; `"pending"`/`"pending_approval"` when either side DOES require it (a
+ * real GroupInvitation record is created instead, delivered to the target as a system notification --
+ * see SystemMessagesView's `group.invitation.created` handling -- and needs their own accept, this
+ * app has no UI surface for the inviter to ever learn the outcome beyond "sent"); `"failed"` with a
+ * `reason`.
+ */
+export interface GroupInvitationResult {
+  user_id: string;
+  status: 'joined' | 'already_member' | 'pending' | 'pending_approval' | 'failed';
+  invitation_id?: string;
+  reason?: string;
+}
+
 export function inviteGroupMembers(topic: string, userIds: string[], message?: string) {
-  return imPost<{ items: Array<{ user_id: string; status: string; invitation_id?: string }> }>(`/groups/${encodeURIComponent(topic)}/invitations`, {
+  return imPost<{ items: GroupInvitationResult[] }>(`/groups/${encodeURIComponent(topic)}/invitations`, {
     user_ids: userIds,
     message,
   });
 }
 
+/**
+ * The target's own action on a `group.invitation.created` system notification (README/docs
+ * :1464/1739 -- doc marks this "待实现" but confirmed by reading im_be's serveIMGroupInvitationResource
+ * directly, it's real and live, same doc-drift as the topic-draft endpoint). Joins the group
+ * immediately on success (no further approval step at this point -- any approval requirement was
+ * already resolved by the invite-creation side choosing "pending"/"pending_approval" as the status
+ * instead of creating a real invitation, or is inherent to a `pending_approval` invitation itself,
+ * which this same endpoint resolves).
+ */
+export function acceptGroupInvitation(invitationId: string) {
+  return imPost<{ invitation_id: string; status: string; topic: string }>(`/group-invitations/${encodeURIComponent(invitationId)}/accept`);
+}
+
 /** Confirmed LIVE (2026-09-09) this does NOT match either the protocol doc's own worked example
  *  (`docs/IM-前后端对接文档.md:1741`, which shows a nested `applicant:{user_id,display_name}`
  *  object) or this file's own previous type -- the real response is a FLAT `user_id` string with no