实现: 家庭模型与成员协作（Flutter AIoT 用户端）

[ronger-x]

Parent PRD: #7

问题

当前 Mortise 只有 member 账号体系，没有面向消费级 IoT 的“家庭”协作模型。Flutter 用户端需要以家庭为中心完成设备自动绑定、共享、切换与权限边界控制，但现有 member 模块缺少家庭实体、成员关系、邀请流程与当前家庭上下文。

本仓库范围

• 在 mortise-member 内扩展家庭领域模型，而不是新建同层业务模块
• 支持家庭创建、编辑、切换、解散
• 支持家庭成员邀请、接受、拒绝、移除、主动退出
• 约束“家庭管理员”能力：仅管理员可邀请/移除成员
• 设备不绑定个人，设备绑定到家庭
• 成员设备操作权限不再细分，家庭成员默认拥有查看与控制权限
• 支持一个账号加入多个家庭，但 App 任一时刻工作在一个当前家庭上下文
• 为其他模块提供稳定的家庭查询与成员校验接口，避免同层直接耦合

验收标准

• 会员可创建家庭并成为管理员
• 管理员可邀请成员加入家庭；被邀请人可接受或拒绝
• 管理员可移除成员；普通成员可主动退出家庭
• 系统能校验“某 member 是否属于某 family，是否为管理员”
• 系统能返回 member 的家庭列表与当前家庭摘要
• 相关 API 使用 member token 鉴权，不依赖后台管理员权限
• 对设备归属的表达以 family 为核心，不泄露后台内部设备凭证
• 为 AIoT、OTA、MQTT 网关提供可复用的家庭查询/校验接口或 SPI，而不是新增同层硬依赖

实现决策

• 家庭能力放在 mortise-member，因为它本质是用户关系与归属模型，而非设备协议模型
• 使用稳定的领域接口向外提供：家庭摘要、成员列表、管理员校验、成员归属校验
• 邀请流程采用显式状态机（待接受、已接受、已拒绝、已取消、已过期）
• 当前家庭上下文由 App 显式传递或后端根据用户偏好记录，避免隐式全局状态
• 与现有 OAuth2 / 手机号 / Email 登录体系兼容，不新增独立账号体系

测试决策

• 覆盖家庭创建、邀请、接受、移除、退出等外部行为
• 覆盖管理员与普通成员的权限边界
• 覆盖成员跨家庭切换与默认家庭选择行为
• 覆盖被移除成员访问家庭资源时的拒绝行为

备注

本 Issue 只负责家庭与成员协作基础模型，不直接实现设备控制页面或 MQTT 订阅。