fix: honor project-range op permissions in UserCanOpDB

[LordofAvernus]

关联的 issue

Fixes actiontech/dms-ee#953

描述你的变更

• UserCanOpDB 与 userCanOpDBWithoutAdminPrivilege 将 op_range_type=project 视为命中项目内全部数据源。脱敏审核（700038）以 project 范围注册、经成员/成员组的「项目管理权限」槽授予，此前不被识别，持有者无法被解析为原文审批人。
• ListUsersOpPermissionInProject 补上成员与成员组项目权限槽的 UNION，使批量查询与单用户查询返回同一套权限。

影响面

脱敏审核之外无行为变化。其余传入 UserCanOpDB / GetCanOpDBUsers 的权限均为 db_service 范围。project 与 db_service 授权入口互斥：角色走 ListMemberOpPermissions（排除 project），成员「项目管理权限」走 ListProjectOpPermissions（仅 project）。

不放开角色挂载 project 范围权限。不改导出工单「待我处理」筛选；Dashboard 待办后续单独做。

测试

• go test -tags dummyhead ./internal/dms/biz/...：TestGetCanOpDBUsers 与 TestUserCanOpDB_ProjectRange 通过，含「仅持有 project 范围脱敏审核的用户不得被导出审批选中」。
• scripts/verify_build_editions.sh：社区版、试用版构建通过。

确认项（pr提交后操作）

Tip

请在指定复审人之前，确认并完成以下事项，完成后✅

---

• 我已完成自测
• 我已记录完整日志方便进行诊断
• 我已在关联的issue里补充了实现方案
• 我已在关联的issue里补充了测试影响面
• 我已确认了变更的兼容性，如果不兼容则在issue里标记 not_compatible
• 我已确认了是否要更新文档，如果要更新则在issue里标记 need_update_doc

---

[github-actions]

PR Reviewer Guide 🔍

(Review updated until commit 11b83c2)

⏱️ Estimated effort to review: 3 🔵🔵🔵⚪⚪

🧪 PR contains tests

🔒 No security concerns identified

⚡ No major issues detected

[github-actions]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
General	优化联合查询逻辑 建议仔细检查 SQL 查询中的参数顺序和 UNION 子句，确保所有查询的参数顺序和条件匹配；同时可以重构或分割复杂的 SQL 语句以提高可读性和维护性。 确认各个 UNION 分支的逻辑是一致的，避免可能的运行时错误。 internal/dms/storage/op_permission_verify.go [447-470] SELECT m.user_uid, p.op_permission_uid, r.op_range_type, r.range_uids FROM members AS m JOIN role_op_permissions AS p ON r.role_uid = p.role_uid UNION SELECT DISTINCT mgu.user_uid, rop.op_permission_uid, mgror.op_range_type, mgror.range_uids FROM member_groups mg JOIN member_group_users mgu ON mg.uid = mgu.member_group_uid JOIN member_group_role_op_ranges mgror ON mgu.member_group_uid = mgror.member_group_uid JOIN role_op_permissions rop ON mgror.role_uid = rop.role_uid -WHERE mg.project_uid = ? and mgu.user_uid in (?) +WHERE mg.project_uid = ? AND mgu.user_uid IN (?) UNION SELECT m.user_uid, mop.op_permission_uid, 'project' AS op_range_type, m.project_uid AS range_uids FROM members AS m -JOIN member_op_permissions AS mop ON m.uid = mop.member_uid AND m.user_uid IN (?) AND m.project_uid = ? +JOIN member_op_permissions AS mop ON m.uid = mop.member_uid +WHERE m.user_uid IN (?) AND m.project_uid = ? UNION SELECT DISTINCT mgu.user_uid, mgop.op_permission_uid, 'project' AS op_range_type, mg.project_uid AS range_uids FROM member_groups mg JOIN member_group_users mgu ON mg.uid = mgu.member_group_uid JOIN member_group_op_permissions AS mgop ON mg.uid = mgop.member_group_uid WHERE mg.project_uid = ? AND mgu.user_uid IN (?) Suggestion importance[1-10]: 6 __ Why: 这个建议提出重构 SQL 的 UNION 分支，特别是将部分连接条件从 JOIN 子句中剥离出来放到 WHERE 条件中，能提高查询的可读性和维护性，但影响有限，因此评分为 6。	Low

[github-actions]

Persistent review updated to latest commit 3fa422b

[github-actions]

Persistent review updated to latest commit 67aaf96

[github-actions]

Persistent review updated to latest commit 11b83c2