feat(project): 添加项目进度自动计算功能

- 在 ProjectMapper 中新增 updateProgressRateById 方法，支持单独更新项目进度
- 在 ProjectService 中新增 recalcProgress 接口，用于重新计算项目进度
- 实现 ProjectServiceImpl 的进度重计算逻辑，通过根任务平均进度更新项目进度
- 新增 ProjectTaskMapper 的 selectRootTaskAvgProgressByProjectId 查询方法
- 在任务创建、更新、删除、状态变更等操作后触发项目进度重计算
- 添加进度归一化处理，确保数值精度为两位小数
- 更新 CLAUDE.md 文档，加强技术风险判断要求

CLAUDE.md

@@ -9,6 +9,7 @@
 - 描述仓库现状以**当前**代码、配置、文档可验证的事实为准；不要拿历史实现、过渡方案或已废弃模型解释当前状态。
 - **输出极简**：先给结论、改动点、必要风险；用自然语言给判断和影响面，少贴代码片段；涉及代码用 `file_path:line_number` 引用；用户追问再展开。
 - **下定论需要充足证据**。疑似 bug 时先判断是否稳定复现：跑了很久没动过的功能**首次**报错，优先怀疑运行时状态污染（devtools / IDE 热替换、ApplicationContext 残留、缓存、Redis / DB 连接、JVM 静态字段被旧 context 设过等），**不要凭单次堆栈就断言代码 bug，更不要直接甩修改方案**。先给"可能原因 + 最便宜的取证步骤"（多数场景是**冷重启 JVM**），用户确认能稳定复现，再讨论代码层面的修复。同款写法在仓库其它位置存在并不能反推"也是 bug"，长期能跑的代码突然失效 ≠ 代码本身错。
+- **技术风险判断（性能 / N+1 / 索引缺失 / 架构缺陷 / 并发安全 / 内存泄漏 等）与"bug 判断"同等严格**：未读到实现层不下结论。不要凭 subagent 摘要、字段名、注释或印象"顺嘴提一句风险/瓶颈/可能问题"——那也是下结论，**且杀伤力更大**：用户会基于"风险提示"决定要不要立项整改。如果当前上下文没核实到实现，就明说"这部分未核实，需要打开 X 文件确认"，不要把猜测包装成"风险提示"塞出去。已识别教训：执行进度查询答完"已批量聚合无 N+1"后又凭印象抛"列表 N+1 风险"，被追问才收回。
 
 ## 本机环境