feat: complete registration invitation and auth redesign

docs/IM-系统设计文档.md

@@ -236,7 +236,9 @@ HTTP API 通用规则：
 
 MySQL 表主键约定：所有 `im_*` 基础表必须具有独立的 `id` 主键。`im_user_security`、`im_kvmeta`、用户资料/隐私、设备 Push Token、好友/黑名单、青少年模式以及群设置/公告已读/禁言等原先使用自然键或复合主键的表，统一改为服务端雪花算法生成的 `BIGINT id` 主键；原业务键保留唯一索引，查询和幂等语义不变。服务启动时会对当前租户库执行幂等迁移，为存量行补齐雪花 ID 后再替换主键。迁移期间不得同时运行不写入 `id` 的旧版本服务。
 
-用户身份字段约定：`im_users.phone` 是注册、密码找回和敏感操作验证使用的手机号真源，新注册必须提供已验证手机号；历史无手机号账号迁移后允许暂时为 `NULL`。`im_user_profiles.email` 仅是未验证的资料字段，不参与登录和密码找回。旧 `im_users.tags` 与 `im_usertags` 已废弃，启动迁移会先从已验证凭证和旧标签回填手机号/邮箱，再删除两者。群组发现仍使用 `im_topics.tags` 与 `im_topictags`，不受本次调整影响。
+用户身份字段约定：`im_users.username` 是非空的主登录账号，`im_users.phone` 是手机号方式的注册号码，允许为 `NULL`；是否完成短信验证由已完成的 `tel credential` 判断。用户填写的普通用户名必须匹配 `^[a-z0-9]{1,10}$`，服务端按原始输入校验；手机号方式写入的 E.164 账号和迁移生成的内部保留账号属于系统值例外。注册页面分别展示用户名和手机号，手机号非空时优先走手机号方式并忽略用户名输入：规范化后的 E.164 手机号同时写入 `username` 和 `phone`；只有手机号为空时才使用用户名方式并只写 `username`。短信关闭时，手机号输入搭配有效邀请码仍按手机号方式注册并写两个字段，但不建立已完成的 `tel credential`。`im_user_profiles.email` 仅是未验证的资料字段，不参与登录和密码找回。旧 `im_users.tags` 与 `im_usertags` 已废弃，启动迁移会先从已验证凭证和旧标签回填手机号/邮箱，再删除两者。群组发现仍使用 `im_topics.tags` 与 `im_topictags`，不受本次调整影响。
+
+注册邀请码固定为 5 位 ASCII 大小写英文字母，使用密码学安全随机数生成并区分大小写。邀请码明文存入租户业务库，`code` 字段使用 `ascii_bin` 排序规则和唯一索引；注册时按完整明文精确查询，不允许大小写转换或模糊匹配。邀请码查看和导出必须授权并审计，普通日志不得记录邀请码。
 
 ### 7.3 企业码与登录流程
 
@@ -250,6 +252,8 @@ MySQL 表主键约定：所有 `im_*` 基础表必须具有独立的 `id` 主键
 
 验证码按 `register`、`login`、`reset_password`、`sensitive_action` 用途隔离，相同验证码不能跨用途使用。数据库只保存验证码强哈希和手机号规范化哈希，明文只在发送时短暂存在。
 
+`im_users.phone` 非空的账号可以通过 `reset_password` 短信挑战自助找回密码；成功验证即证明当前持有该号码，不要求注册时已经存在完成状态的 `tel credential`，并可在重置成功后补建凭证。`phone=NULL` 的用户名账号不提供自助找回，只能由当前租户管理员重置。管理员不得跨租户操作，重置行为必须进入安全审计。
+
 密码重置必须在同一事务中完成：
 
 1. 消费有效验证码或二次验证挑战。