Merge branch 'test-202609v1' into test-202609v2

# Conflicts:
#	specs/017-oauth-login/plan.md
#	specs/017-oauth-login/spec.md
#	specs/017-oauth-login/tasks.md

specs/017-oauth-login/plan.md

@@ -138,3 +138,10 @@ cid, cidType, deviceToken, voIPToken
 - JDK 21 定向测试与 `ruoyi-admin` 模块编译。
 - 真实 LINE Channel code、回调地址和三个 App scheme 仍需客户端联调验证。
 - `state` 的完整 CSRF 防护需服务端签发/消费并由三个 App 保存、回跳比对，作为三端协议联调项统一实施，不能只改单侧回调。
+
+## 2026-09-24 后续增量计划（待实施）
+
+1. 扩展 `info_user_oauth`，新增可空字段 `provider_display_name`，为每个绑定身份保存第三方显示名称；迁移 SQL 按项目规则写入 `updatesql/sql.md`，不直接执行。
+2. LINE 登录校验取得 Profile 时保留 `displayName`，按 `(provider, provider_uid)` 更新该绑定名称；资料暂不可用时保留旧值。Apple 首次授权时由 App 获取共享的 `fullName` 并随凭证提交，后端在验证 Apple 身份后保存；历史空值不强制补录。
+3. 用户资料响应从当前登录会话确定渠道及对应绑定身份，提供该身份名称；仅凭 `user_id` 或 `provider` 不应在同一用户绑定多个同渠道身份时任意取一条。App 将其与 `info_user.nick_name` 分开显示；原有昵称修改接口不变。名称为空时只显示渠道，不以用户昵称冒充第三方名称。本增量不在 `info_user` 写“最近登录渠道”。
+4. 验证 LINE 名称变化、Apple 首次有名/无名及历史空值、同一用户多渠道切换、不同 `user_id` 不串名，并联调 App 展示。以上均为计划，尚未实现或验证。

specs/017-oauth-login/spec.md

@@ -28,7 +28,7 @@ C 端 app 现仅支持「手机号 + 短信验证码」登录（`/infouser/user/
 - **FR-002**: 凭证校验三选一：Apple=验 ES256 identityToken 取 sub；Google=tokeninfo HTTP 验真取 sub 并校 audience；LINE=前端传授权 code，后端用 code+clientSecret+clientId 向 `oauth2/v2.1/token` 换 access_token，再调 v2/profile 取 userId（Authorization Code 流程，不直接收前端 accessToken）。
 - **FR-003**: 按 (provider, providerUid) 查 `info_user_oauth`：命中→校验用户 status/del_flag 正常后直接签发 token（claim `provider`）返回；未命中→缓存 {provider,providerUid} 到 Redis(短TTL)，返回 `needPhone` + tempKey。
 - **FR-004**: 提供 `POST /infouser/user/oauthBindPhone {tempKey, phone, code, ...}`：取回缓存的 providerUid + 验短信码（复用 lodeing 逻辑，含万能码 8888）→ `getuser(phone)`：已注册→关联；未注册→`createUser` 新建；随后 insert `info_user_oauth(user_id, provider, provider_uid)`。
-- **FR-005**: 新建用户昵称统一用手机号（与现有 createUser 一致），avatar 留空，不用 provider 的昵称/头像。
+- **FR-005**: 新建用户的 `info_user.nick_name` 统一用手机号（与现有 createUser 一致），avatar 留空；三方资料不得覆盖用户主昵称/头像。第三方名称的独立展示见下方 2026-09-24 后续增量。
 - **FR-006**: token claim 增加 `provider` 字段（apple/google/line_user/line_rider/line_merchant；手机号登录为 phone），供登录渠道统计或「未绑手机限制」类约束使用。
 - **FR-007**: 登录端点 `@Anonymous` 放行；受保护接口继续走 `@Auth`，零额外接入。
 - **FR-008**: 凭证校验失败 / tempKey 过期 / 短信码错误 → 明确错误提示，不签发 token、不建账号。
@@ -66,3 +66,12 @@ C 端 app 现仅支持「手机号 + 短信验证码」登录（`/infouser/user/
 - 后台管理端解绑/查看三方绑定（后续增量）。
 - 第三家以上三方（微信/Facebook）——表结构已可扩展，但本期只接 Apple/Google/LINE。
 - Apple 隐藏邮箱中转、refresh_token 续期等高级场景。
+
+## 2026-09-24 后续增量：登录渠道与第三方名称展示（待实施）
+
+- 用户端分别展示原有 `info_user.nick_name`、本次登录渠道（Apple / LINE）及该渠道的第三方名称。用户修改昵称仍走原有资料修改流程；切换登录渠道不得覆盖 `info_user.nick_name`，也不得把不同 `user_id` 的三方身份视为同一账号。
+- `info_user_oauth.user_id` 只表示账号绑定关系，不表示“最近一次登录”。当前 `provider` 记录在本次登录的 JWT 会话中，`info_user` 不保存最近登录渠道；本增量展示的是本次会话的登录方式，不是跨设备共享的历史“最后一次登录方式”。
+- 第三方名称按绑定身份独立保存于 `info_user_oauth.provider_display_name`（新增可空字段）；本次登录为 LINE 时显示 LINE 名称，为 Apple 时显示 Apple 名称，不使用其他渠道的名称。当前表尚无此字段，待实施后才可用。
+- LINE：每次成功登录且取得带 `profile` 权限的资料时，读取 `displayName` 并刷新对应绑定记录；获取失败时保留已保存的名称，不影响登录。
+- Apple：首次授权取得用户共享的 `fullName` 时保存到对应绑定记录；后续登录不要求再次取得名称。历史账号未保存过 Apple 名称或用户未共享名称时，该名称允许为空，用户端仅展示“Apple 登录”及原有昵称，不伪造 Apple 名称。
+- 本增量仅记录需求，尚未修改 App、后端、数据库或现有账号数据；实施时须同步更新接口契约、数据模型、SQL 和验证用例。

specs/017-oauth-login/tasks.md

@@ -66,3 +66,11 @@
 > 2026-09-04 另执行完整 reactor test：`ruoyi-system` 53 tests 全通过，`ruoyi-admin` 371 tests 中 370 通过、1 error。失败项为既有 `PosOrderQsOprateControllerTest.newTasksContainOnlyPaidOrdersWaitingForRiderBeforeMerchantAcceptance` 未注入 `UserService` 导致 NPE，与 017 修改文件及定向测试无关，本次不跨范围修改。
 
 > 交付记录（2026-09-04）：最终代码复核未发现剩余 Critical/Important；`git diff --check` 通过；数据库迁移未执行，须先运行 `updatesql/sql.md` 中两项冲突预检再由开发者手工执行；017 修改当前保留在工作区，尚未提交。
+
+## 2026-09-24 后续增量待办：登录渠道与第三方名称展示
+
+- [ ] T29 为 `info_user_oauth` 增加可空字段 `provider_display_name`，并将迁移 SQL 记录到 `updatesql/sql.md`（不直接执行）。
+- [ ] T30 LINE 登录每次成功读取并刷新本渠道 `displayName`；读取失败保留旧值、不阻断登录。
+- [ ] T31 App 首次 Apple 授权取得 `fullName` 时传给后端；后端验证身份后保存到对应 Apple 绑定，历史无名称允许为空。
+- [ ] T32 用户资料接口与 App 分别展示原有昵称、本次登录渠道及对应第三方名称；昵称修改流程不变，空名称只显示渠道。
+- [ ] T33 编写并运行渠道切换、跨账号隔离、LINE 名称更新、Apple 首次/历史空值及 App 展示的定向验证。