feat(system): 扩展用户部门权限功能

- 在 AdminUserService 中新增 listEnabledUserIdsByDeptIds 方法获取指定部门集合下启用且未离职的用户 ID 集合
- 在 DeptService 中新增 listDescendantDeptIds 方法获得指定部门集合及其所有子孙部门的 ID 集合
- 在 DeptService 中新增 listCodesByIds 方法按 id 集合批量查询部门 code 集合
- 在 OrgLeaderRelationService 中新增 listEffectiveDeptIdsByUserId 方法查询指定用户当前生效的负责人关系所对应的 dept_id 集合
- 在 PermissionApi 中新增 isSuperAdmin 接口判断用户是否超管
- 在 ObjectPermissionApi 中新增 getObjectRolePermissionDetailMerged 接口按 roleId 列表聚合菜单 + 权限码
- 扩展 ProductContextRoleRespVO 添加多角色场景的附加角色名称列表
- 扩展 ProductCreateWithTeamReqVO 支持创建时添加关心人用户 ID 列表
- 优化 ProductMemberServiceImpl 支持同一用户多角色显示，区分主角色和附加角色
- 新增 MEMBER_ACTION_REACTIVATE 复活动作类型用于处理 INACTIVE 成员行重新激活场景
- 在 ObjectStatusModelDO 中新增 progressExcludedFlag 字段控制是否参与上层进度统计
- 更新 AGENTS.md 和 CLAUDE.md 添加 Git 操作纪律规范
- 在 rdms-project-api 中新增多个错误码常量支持角色转移和内置角色配置验证

AGENTS.md

@@ -227,6 +227,28 @@ rdms-xxx
 8. 修改跨模块使用的 API 时，需要同时更新提供方实现和对应的 `rdms-system-api` 或对应 `rdms-xxx-api` 契约。
 9. 除非用户明确要求，否则不执行任何编译、构建、测试、打包或其他会实际运行项目的命令，包括但不限于 `mvn`、启动命令和脚本。
 
+## Git 操作纪律
+
+### 默认不引导分支管理（**首要**）
+
+用户在本仓库长期固定在 `main` 上工作。开发流程中：
+
+- **不要主动建议建 feature 分支**（`git checkout -b feat/xxx`、`git switch -c ...`）。
+- **不要把"先切到 xxx 分支再操作"作为方案前置步骤**。
+- 一切围绕 `main` 展开：直接在 `main` 上改、`main` 上提交、`main` 上推。
+- 例外：用户明确要求建分支、或涉及多人协作 / PR 评审 / 大规模重构（此时仍只是"提一句作为可选"，不强推）。
+
+理由：曾出现一次"误把文件名当分支名建出怪分支 `用户行动清单.md`，后续 `git branch -D` 删分支时险些丢用户 3 天工作"的事故。事故根因就是分支管理本身——少走分支 = 少埋雷。
+
+### 破坏性 git 命令必须先核实
+
+任何**会丢工作**的 git 命令——`branch -D`、`reset --hard`、`clean -fd`、`push --force` / `--force-with-lease`、`checkout` / `switch` 带未提交改动、`rebase` 在已推送分支上、直接动 `.git/` 内部文件（`refs/`、`HEAD`、`packed-refs`）——**给出建议前必须先核实**，不得凭"看起来安全"就甩命令：
+
+1. **目标 ref 上是否有未推送 / 未合并 commit**：让用户跑 `git log --oneline -5 <ref>` 或 `git log <主线>..<ref>` 把输出贴回来。
+2. **工作区是否干净**：`git status`。
+3. **先挂救生圈**：建议用 `git tag backup-xxx <sha>` 锁定当前 SHA，**再执行**破坏性命令。
+4. **明示翻车回滚路径**：例如"如果不对，`git reset --hard backup-xxx` 即可回到此处"。
+
 ## 测试指引
 
 先定义验证方式，再实施修改。默认通过以下方式验证：