issue: a deleted sidebar folder keeps 404ing shared chat requests for the rest of the session

快速结论：该报错在 Open WebUI 侧边栏中删除一个曾展开过的文件夹后出现，客户端会在本次页面会话内持续对该已删除文件夹的 ID 发起 GET /api/v1/folders/{deleted_id}/shared/chats 请求并收到 404。优先检查 RecursiveFolder.svelte 的 onDestroy 是否清理了共享的 folderRegistry 条目。

适用环境：Open WebUI（最新 dev 分支，提交 b3591e60b），Docker 安装，Ubuntu 客户端 + Linux 服务器，Firefox 浏览器。

最快修复方案：暂无官方确认发布的一步修复方案。Issue 中已验证的补丁（对应 PR #29173）是在 src/lib/components/layout/Sidebar/RecursiveFolder.svelte 的 onDestroy 回调中增加一行 delete folderRegistry[folderId];。该补丁已在复现环境中确认有效，如果你自行编译前端，可优先尝试。

注意事项：此补丁属于对共享注册表的对称清理修复，未在官方稳定版中验证。Issue 作者确认所有消费方已经使用可选链（folderRegistry[id]?.setFolderItems?.()），卸载后重新挂载的文件夹会在 onMount 中重新注册，因此标记已读等广播行为不受影响；但该结论基于代码分析，仍需在实际部署中进一步观察。

问题场景

在 Open WebUI 的侧边栏中，如果某个文件夹曾经被展开过（其组件已挂载并注册），之后该文件夹在其他位置（例如另一个浏览器标签页或通过 API）被删除，那么在当前页面的会话内，每次侧边栏刷新或保存任意文件夹的编辑时，客户端都会重复向已删除文件夹的 ID 发起 GET /api/v1/folders/{deleted_id}/shared/chats 请求，服务器返回 404，且该现象会持续到页面关闭为止。

报错原文

issue: a deleted sidebar folder keeps 404ing shared chat requests for the rest of the session

The console shows a 404 on `/api/v1/folders/{id}/shared/chats` for a folder id that no longer exists, immediately followed by a 200 on `/api/v1/chats/folder/{id}/list` (the code's own error fallback). The pair reappears on every sidebar refresh, indefinitely, within the same page session.

save 1: /folders/311a76b2/shared/chats -> 404, three real folders -> 200
save 2: /folders/311a76b2/shared/chats -> 404, same three -> 200

原因分析

原因是客户端侧边栏文件夹组件的生命周期清理不完整。每个侧边栏文件夹在挂载（onMount）时，会在一个共享的 folderRegistry 对象中注册回调；但 onDestroy 只移除了拖拽事件监听器，没有删除对应的注册条目。当文件夹在别处被删除后，该组件已经卸载，但注册表里仍然保留着对已删除文件夹 ID 的闭包引用。此后，侧边栏的 setFolderItems() 逻辑会遍历注册表中的所有条目（包括这些已卸载组件的残留项），对已删除的文件夹 ID 调用 getSharedFolderChats()，服务器正常返回 404，代码的 catch 分支又回退请求普通的聊天列表（返回 200），于是控制台出现了“404 + 200”的请求对。

环境排查

Open WebUI 版本：确认是否在最新 dev 分支（提交 b3591e60b）或包含 onDestroy 清理逻辑的修复版本上。
安装方式：Docker 部署环境中确认前端静态资源是否包含该修复补丁。
浏览器：Firefox（Issue 中已确认）；其他浏览器未在 Issue 中验证，但建议同步检查。
服务器端：确认文件夹确实已从数据库表删除，且没有其他服务端错误；此问题与 Python/CUDA 等后端依赖无关。

解决步骤

确认问题现象：在侧边栏展开一个文件夹，然后在另一个标签页或通过 API 删除该文件夹，回到原页面编辑任意剩余文件夹并点击“保存”，观察控制台是否出现 /folders/{deleted_id}/shared/chats 的 404 请求。
定位前端源码文件：检查 src/lib/components/layout/Sidebar/RecursiveFolder.svelte 中的 onDestroy 回调，确认是否存在删除共享 folderRegistry[folderId] 条目的逻辑。
如果运行的是自行构建的前端，应用 Issue 中提交的补丁：在 onDestroy 回调开头加入 delete folderRegistry[folderId];（可参考 PR #29173 的单提交、6 行改动）。
重新构建前端并部署，再次执行上述复现步骤。
如果使用官方 Docker 镜像且问题依旧，等待官方发布包含此修复的新版本，或在 Issue 中补充你的环境信息。

验证方法

按复现步骤操作后，打开浏览器开发者工具的网络面板，确认不再出现对已删除文件夹 ID 的 /api/v1/folders/{id}/shared/chats 请求（即没有 404）。在侧边栏中保存任意文件夹的编辑并刷新侧边栏，控制台中不应再出现该 404 请求。同时确认正常的文件夹共享聊天列表加载不受影响，仍然返回 200。