Bug: Provider删除时的提示弹窗CSS层级问题
快速结论：在 LobeChat 的 Provider 设置面板中，点击删除按钮后，确认弹窗（Confirm Modal）可能渲染在 Provider 配置抽屉（Drawer）下方，导致无法点击。优先检查弹窗是否应用了正确的 `getContainer` 配置。
问题场景
此问题出现在 LobeChat 的 Settings → Provider 配置页面中。用户通过 Web 端（如 Chrome 浏览器）在 Provider 设置面板内点击某个提供商的删除按钮（如图 2 所示），触发删除确认弹窗（如图 1 所示）。弹窗被错误地渲染在 Provider 配置的 Modal/Drawer 层级之下，导致用户无法正常操作弹窗。
报错原文
Issue 标题：Bug: Provider删除时的提示弹窗CSS层级问题
描述：点击删除后，弹窗层级小于Provider配置Modal
（无控制台错误日志，为纯 CSS 层叠上下文 Bug）原因分析
根本原因是一个 CSS 层叠上下文 / z-index 层级问题。删除确认弹窗（通常由 antd 的 `Modal.confirm` 或类似 UI 组件渲染）没有正确地挂载到 Provider 配置抽屉的层叠上下文之上。
这属于 LobeChat 已知的一系列层级 Bug 之一。团队已通过迁移至 @lobehub/ui/base-ui 来系统性地解决此类问题（利用 floating-ui 的 FloatingTree 原生管理层级，而非手动 z-index）。当前场景下，删除 Provider 的确认弹窗很可能仍在使用旧的层级管理方式，尚未应用修复。
环境排查
- LobeChat 部署版本：Issue 提及为官方云最新版（Web 端）。
- 操作系统：macOS（可跨平台复现）。
- 浏览器：Chrome。
- 相关依赖：antd 版本、
@lobehub/ui版本（是否为 base-ui 版本）。 - 复现稳定性：用户反馈删除时稳定复现。
解决步骤
- 定位弹窗渲染层级（可优先尝试）：排查 Provider 删除按钮触发的确认弹窗是否使用了
getContainer={false}。设置getContainer={false}可以确保弹窗直接挂载到body下，通常会位于最高的层叠上下文之上。相关修复案例：PR #14282（Drawer stacking context fix）。 - 迁移至 base-ui 的 Popover/Modal：如果弹窗使用了旧的 antd
Popover或Modal，请将组件替换为@lobehub/ui/base-ui的Popover，使其与 Provider 配置面板共享同一个FloatingTree上下文，从根本上解决嵌套层级问题。相关修复案例：PR #15401（Nested popover stacking）。 - 检查父级容器的层叠上下文：如果 Provider 配置面板内部使用了类似
getPopupContainer的属性来限定弹出层父节点，请确保在删除弹窗的场景下，弹窗的父节点正确锚定在 Provider 配置面板的popover内部，避免被外部容器截断层级。相关修复案例：PR #14269（Dropdown containment in popovers）。
验证方法
在 Settings → Provider 页面，点击任一 Provider 的删除按钮。确认弹窗应正常显示在 Provider 配置抽屉的最上层，所有按钮可点击，且不会遮挡配置面板的关闭或保存按钮。
参考来源
lobehub/lobe-chat #15836（讨论中包含 @ONLY-yours 的确认报告以及 @dosu 提供的详细分析与历史修复链接）
