修复全页面走查发现的问题（第二批：登录、通讯录、群聊）

第1章
- tinode-web: 手输密码登录失败会 navigateTo('') 把用户弹回企业码页，刚输的账号丢了，而
  TenantEntry 不渲染 FormAlert，那句错误提示根本看不到。改成只有存储的 token 失效才回登录入口。
- auth-onboarding IdentityCheck: 限流 429 时服务端会连同未过期的 challenge_id 一起返回，
  原来只显示错误文案、challengeId 留空，于是 submit 开头的守卫静默吞掉点击——输完验证码点
  "确定"毫无反应也无提示。同文件 VerificationButton 早就处理对了，这里是漏抄。
- auth-onboarding Register: 手机号注册路径硬传 invite_code:''，把用户填的邀请码丢了。后端
  user.go:175-181 对邀请码的校验和 RecordUse 不区分注册路径，UI 上也摆着这个输入框。

第5章
- 好友列表主副行显示同一串字：后端在有备注时把 display_name 也设成备注（im_http.go:8500-8507），
  两个字段同值。加"不同才显示"的守卫。
- 拉黑确认弹窗把设置页当背景渲染并摆出"操作之后"的样子，但背景组件自己的 getUserProfile
  回来后又把开关改回未拉黑、"删除好友"红条重新冒出来。加 pinBlocked 挡住这次覆盖。

第6章
- 群列表把群名显示成 topic id、成员数恒为 0。根因在后端：handler 用 store.Users.GetSubs，而
  store 自己的注释就写着它 "Does not load Public/Trusted or Private"（store.go:834-835），
  groupListItemPayload 却去读 sub.GetPublic()/GetSubCnt()（应该用 GetTopics）。已记为后端问题；
  前端先用本地 Tinode 会话缓存兜底（消息首页一直这么取，是准的）。
- 禁言页每行头像画成群组图标（Avatar 兜底图标默认 'group'，没传 icon="person"），
  且顺带从成员表带上真实头像。
- 禁言页"以上成员不允许发言"被当成空状态用，语义正好反了——有禁言成员时这句消失、
  一个都没有时反而显示。改为列表下方常驻注脚，空态另给文案，并补 .group-inline-note 样式。
- bytesToGB 只输出到 MB，1.4GB 的文件显示成 "1433.6 MB"。
- 群文件"来自"直接显示裸 uploader_id（groupFilePayload 不给昵称），拉成员表交叉引用。
- 群公告从聊天页横幅进入后返回，会把会话一起关掉：navigate 只写 query 参数，path[1] 仍为空，
  handleHashRoute 就把 topicSelected 清成 null。Header 支持 onBack，显式把 topic 写回 path[1]。
- 群成员点头像打不开非好友资料页：目标页先读 'profile-seed:' 缓存，因为 getUserProfile 对
  非好友直接 403。第5章入口一直有 seed，这里漏了。
- 群简介上限 225 超过后端硬限 200（im_http.go:4667），写满必被打回。

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

src/views/auth-onboarding-view.jsx

@@ -422,7 +422,11 @@ function Register({errorText, errorLevel, onImRegisterRequest}) {
         // set a nickname afterwards).
         const secretAccount = form.username || ('+86' + form.phone);
         onImRegisterRequest(secretAccount, form.password, form.username || '',
-          {username: form.username || '', phone: form.phone, invite_code: ''},
+          // 邀请码不能在手机号路径上丢掉：后端 user.go:175-181 对邀请码的校验和 RecordUse 都不区分
+          // 注册路径（`if inviteCode != ""` 就会校验并记录），而且 user.go:169 的
+          // inviteRequired 在短信通道关闭时对手机号注册同样为真。UI 上明明摆着邀请码输入框，
+          // 原来却硬传空串，用户填了也被静默丢弃，邀请来源统计全丢。
+          {username: form.username || '', phone: form.phone, invite_code: form.invite || ''},
           {meth: 'tel', val: form.phone, resp: verified.verification_token, params: {challenge_id: challengeId}});
       } else {
         onImRegisterRequest(form.username, form.password, form.username,
@@ -546,6 +550,20 @@ function IdentityCheck({authenticated}) {
       setSeconds(data.resend_after_seconds || 60);
     } catch (err) {
       setError(err.reason === 'REALNAME_REQUIRED' ? '需要先完成实名认证并绑定手机号' : (err.message || '获取验证码失败'));
+      // 限流（429）时服务端会连同还没过期的 challenge_id 和剩余冷却秒数一起返回
+      // （im_http.go:6361-6367）。原来这里只把错误文案显示出来就完了，challengeId 一直是空串，
+      // 于是 submit() 开头的 `if (!challengeId) return` 会静默吞掉点击——按钮看着能点，
+      // 输完 6 位验证码点"确定"毫无反应，也没有任何提示。同文件的 VerificationButton
+      // 早就处理对了，这里是漏抄。
+      if (err.details && err.details.retry_after_seconds) {
+        setSeconds(err.details.retry_after_seconds);
+      }
+      if (err.details && err.details.challenge_id) {
+        setChallengeId(err.details.challenge_id);
+      }
+      if (err.details && err.details.phone_mask) {
+        setPhoneMask(err.details.phone_mask);
+      }
     } finally {
       setBusy(false);
     }