feat(file): 改造文件上传接口返回结构

- 将 POST /system/file/upload 接口返回结构从 string 改为 { id: string, url: string }
- id 字段以字符串形式返回 infra_file.id，避免 JavaScript 数值精度丢失问题
- 保持接口路径、方法和入参完全不变，仅修改返回格式
- 添加 GET /system/file/download 接口用于文件下载功能
- 优化 AppFileController 中的文件上传实现逻辑
- 更新 AuthConvert 和 AuthUserInfoRespVO 添加用户昵称和头像字段
- 在 CLAUDE.md 中补充鉴权通道和 HTTP 动词语义说明文档
- 在 ErrorCodeConstants.java 中添加多个项目管理和执行相关的错误码定义
- 删除执行成员相关的数据库表和接口定义（执行协办人替代方案）
- 在 FileMapper 中增加按 URL 查询文件的方法支持

CLAUDE.md

@@ -9,6 +9,7 @@
 - 描述仓库现状以**当前**代码、配置、文档可验证的事实为准；不要拿历史实现、过渡方案或已废弃模型解释当前状态。
 - 回答保持精简，先给结论、改动点、必要风险；细节等用户追问。
 - **不要废话**：默认极简输出，不展开背景、不复述需求、不堆叠章节标题；能用一两句讲清就别写成清单；用户主动追问再展开。
+- **回答问题时不要过多代码层面的描述**：默认用自然语言给结论、判断、影响面；除非用户明确要看实现细节，不要大段贴代码片段、不要逐行解读、不要把分析写成"先看 xxx.java 第 N 行"的形式。涉及代码定位时用 `file_path:line_number` 引用即可。
 
 ## 本机环境
 
@@ -64,9 +65,42 @@
 ## 认证与跨模块调用
 
 - 默认沿用 OAuth2 / Token / `LoginUser` / `login-user` 透传主链。**不要**另造 ThreadLocal / Session / 自定义 header。
-- 接口级权限走 `@PreAuthorize("@ss.hasPermission(...)")`，不要绕开。
 - 跨模块/跨服务必须通过 `*-api` 模块定义契约；不要直接依赖别人的 `*-boot`。
 
+### 鉴权：必须按"全域 / 对象域"分通道挂
+
+系统有**两条互不交叉**的权限通道，挂错通道 = 永远 403。新增/修改接口前必须先判断它属于哪一域：
+
+| 通道 | 适用场景 | 注解 / 实现 | 角色与菜单 |
+|---|---|---|---|
+| **全域 global** | 传统 RBAC 顶层菜单与"项目管理界面"——选择对象**之前**的所有动作（建项目、列项目、菜单/角色/用户管理等） | Controller 上 `@PreAuthorize("@ss.hasPermission('xxx')")`，由 `PermissionServiceImpl.hasAnyPermissions` 处理 | `system_role.scope_type='global'` + `system_menu.scope_type='global'` |
+| **对象域 object** | 用户**已选择某个对象**（如某个项目/产品）后，对象内部的一切操作（任务、执行、工时、协办人、需求、成员维护等） | Service 上 `@CheckObjectPermission(objectType=..., objectId="#xxxId", permission="...")`，由 `ObjectPermissionAspect` → `ObjectPermissionService.checkPermission` 处理 | `system_role.scope_type='object'` + `system_menu.scope_type='object'` + `object_type` |
+
+红线：
+
+- **对象内接口绝不能挂 `@PreAuthorize("@ss.hasPermission(...)")`**。该注解走的链路在 `PermissionServiceImpl` 里强制按 GLOBAL 取角色（line 343-347）+ 强制按 GLOBAL 查菜单（line 92-94），对象域角色与对象域菜单都进不来，即使授权配置完全正确也必然 403。
+- **对象域权限校验必须落在 Service 层 `@CheckObjectPermission`**，原因：路径里 `objectId` 通常以 `#projectId`/`#productId` 等 SpEL 解析，Controller 的参数校验前置阶段不便复用；与同模块（`ProjectMemberServiceImpl` / `ProjectExecutionServiceImpl` / `ProjectExecutionAssigneeServiceImpl` / `ProjectTaskServiceImpl`）保持一致。
+- **同一接口不要两条通道叠加**。要么全域，要么对象域；叠加只会让对象域用户被全域那条卡死。
+- 列表/详情这类对象内**读路径**目前未挂 `@CheckObjectPermission`（属已识别负债，台账 TD-001），新增读接口暂沿用现状即可，不要顺手改造，等独立立项。
+
+判定口诀：**URL 里有 `{projectId}` / `{productId}` 等对象 ID → 对象域；没有 → 全域**。
+
+## 接口语义(HTTP 动词)
+
+本仓库 update 类接口默认按 RESTful 标准用 HTTP 动词区分语义,前后端必须按下表对齐,避免"前端没传字段"和"前端想清空"在后端无法区分的歧义。
+
+| 动词 | 语义 | 字段处理规则 |
+|---|---|---|
+| **PUT** | 全资源替换 | 前端必须把表单完整状态回传(读到的非必填字段也要原样回传)。后端按字段值落库:**有值=更新,`null`=清空**。DO 字段加 `@TableField(updateStrategy = FieldStrategy.ALWAYS)` 跳过全局 `NOT_NULL` 让 `null` 真的写库 |
+| **PATCH** | 部分字段更新 | **本仓库暂不引入 PATCH 接口**。如果有"只改一两个字段"的需求,用专门的子动作接口(参考 `assignees/{id}/inactive`、`status` 这种语义化路径),不要在 update 接口里靠旁路标记(如 `clearXxx: true`)模拟 PATCH |
+| **DELETE** | 资源删除 | 软删走全局 `deleted` 列,不需要参数 body |
+
+红线:
+
+- **不要在 update 类接口的 ReqVO 里加 `clearXxx: Boolean` 这种旁路标记**来模拟 PATCH —— 等于承认接口是"伪 PATCH",会让所有非必填字段都需要类似标记,长期污染 API 设计。需要部分更新就拆子动作接口。
+- 新增 update 接口时,必须在 API 文档对应章节明示"PUT 全字段回传"约定;DO 上对允许 null 的字段补 `FieldStrategy.ALWAYS` 注解,并加注释说明语义来源(指向本节)。
+- 历史接口若是稀疏 PATCH 风格(传 null = 不动),保留现状但不要拓展;遇到清空诉求时按 PUT 方向重构。
+
 ## 数据与 SQL
 
 - 新表 DO 复用现有 `BaseDO` / 审计字段风格，不要再引一套审计基类（除非该表本身明确不需要逻辑删除）。