Code Review

严重 Bug 1 — 升级后所有项目消失

server/projects.js 的 getProjects() 现在完全依赖 DB 的 projects 表，不再扫描文件系统。首次升级时 DB 为空，projectDb.getAllProjects(userId) 返回 []，用户看到 0 个项目。

现有的 migrateLegacyProjects() 只处理 vibelab → dr-claw 工作区重命名，不处理从 ~/.claude/projects/ 到 DB 的通用迁移。

需要：添加首次运行时从文件系统扫描并填充 projects 表的迁移逻辑。

严重 Bug 2 — 永久删除可能误删其他项目

deleteTrashedProject() 的 physical 分支：

await fs.rm(trashMeta.originalPath, { recursive: true, force: true });

如果用户 trash 了项目 A（路径 /home/user/my-project），然后在相同路径创建了项目 B，再回到垃圾箱永久删除 A，会 rm -rf 掉项目 B 的文件。没有验证该路径是否仍属于被删项目。

建议：删除前检查目录内容是否与原项目匹配（如比较某个标识文件），或至少二次确认。

严重 Bug 3 — logical delete 标记无限增长

deleteTrashedProject() 的 logical 分支在 project-config.json 写入 { deleted: { deletedAt } } 后直接 return true，后面的 delete config[projectName] + saveProjectConfig() 永远不会执行。这些标记会无限积累。

中等问题

• 多用户信息泄露：getTrashedProjects() 中 config-only 的 trash 项目（dbEntry 为 null 或 user_id 为 null）对所有用户可见
• SQLite 变量数限制：getSessionsByProjects() 的 IN (...) 子句无上限，超过 SQLite 默认 999 变量限制会报错
• restoreProject 不验证路径：restore 在 metadata 层面成功，但 originalPath 可能已被删除或移动
• Config 文件写竞争：deleteProject、restoreProject、deleteTrashedProject 都做 loadProjectConfig() → saveProjectConfig()，无锁。并发操作可能互相覆盖
• TypeScript 类型错误：SidebarModals.tsx 中 [...projects, ...trashProjects].map(normalizeProjectForSettings)，TrashProject[] 缺少 Project 的必要字段（sessions、sessionMeta、taskmaster 等），应该编译失败（但 CI 通过了，需确认）

小问题

• 3个死函数（sanitizeTrashName、getProjectsTrashRoot、movePathSafely）和1个未使用常量 PROJECTS_TRASH_DIR_NAME，看起来是废弃设计的残留
• TrashDashboard 无 loading 状态，初始会闪现 "Trash is empty"
• currentTime 只在渲染时计算一次，"Deleted X ago" 时间戳不会更新
• 每次项目刷新都额外请求 /api/projects/trash，大多数用户不需要
• 错误提示用 window.alert() 而非应用内 toast/notification
• encodeProjectPath 在 server/utils/sessionIndex.js 中重复定义
• Trash 项目出现在 Settings 的项目下拉列表中，可能造成用户困惑

Thanks @Zhang-Henry for your comprehensive review! I already fixed them with a new commit.