修复菜单管理在modern表结构下删除失败

Co-authored-by: multica-agent <github@multica.ai>

memory/2026-05-03.md

@@ -259,6 +259,28 @@
   - 文件：`web/src/app/admin/workers/page.tsx`
     - Worker 列表与单 worker 任务请求均改为 `forceRefresh=true`，页面默认拉取实时数据。
 
+## Work Log - 菜单管理支持删除（2026-05-03）
+
+- 背景：
+  - Issue `FL-185` 反馈“菜单管理要支持删除”。
+  - 前端已有删除入口，但后端删除逻辑主要按 legacy 表（`menu` / `role_menu_rela`）执行，在 modern 表结构（`menus` / `role_menus`）下会删除失败。
+
+- 本次改动（最小闭环）：
+  - 文件：`api/app/services/legacy_admin_rbac_service.py`
+  - `delete_menu` 增加数据源分支：
+    - legacy：保留原有删除流程（`menu` + `role_menu_rela`）；
+    - modern：新增 `menus` + `role_menus` 删除路径，支持按 `id` 或 `code` 解析菜单。
+  - 新增 `_legacy_menu_table_exists`，通过 `to_regclass('public.menu')` 判断是否走 legacy 分支。
+  - 扩展 `_get_users_with_menu_access`，支持按 `role_source` 查询 legacy/modern 角色菜单关联，确保删除后权限缓存刷新用户范围正确。
+  - 保持既有保护规则不变：
+    - 受保护菜单编码仍禁止删除；
+    - 存在子菜单时仍禁止删除；
+    - 删除后继续发布 `admin.menus` 变更事件，前端列表与侧边菜单自动刷新。
+
+- 风险与影响：
+  - 影响面仅后台菜单删除服务层；菜单新增、编辑、查询与权限模型未改。
+  - 若目标菜单存在子菜单或在保护名单中，行为仍与历史一致（返回不可删除）。
+
 - 验证：
   - 代码路径校对：前端监控页 -> `/api/v1/admin/flower/workers` -> Flower `/api/workers` 代理链路保持不变，仅调整刷新策略与容错。
   - 自动注册路径校对：`worker_ready/heartbeat_sent/worker_shutdown` 仍通过 `worker_registry_service` 入库，仅修正 worker 名标准化逻辑。