fix(desktop): 避免 Provider I/O 阻塞 Windows 界面线程

[TorbenXiong]

背景

桌面端启动时会读取本地 Provider 配置。变更前，Provider 目录枚举、文件读取和 JSON 解析均由同步 Tauri command 执行，系统托盘初始化也会同步执行相同操作。

在 Provider 文件较多、文件异常膨胀、磁盘响应较慢或文件受到安全软件扫描时，这些同步 I/O 可能阻塞 Windows 界面线程，导致窗口首帧白屏或短暂无响应。

一般只有少量 Provider 时，修复前后的性能差异通常不明显。本次修改主要用于消除潜在的界面线程阻塞，提高异常和高负载场景下的稳定性。

修改内容

• 将 list_providers 改为异步 Tauri command。
• 使用 blocking worker 执行 Provider 目录枚举、文件读取和 JSON 解析。
• 调整 Web/Headless 兼容层，等待异步 Provider 查询结果。
• 系统托盘启动时先显示轻量占位菜单。
• 在后台构建和刷新完整托盘菜单，避免阻塞界面线程。
• 为托盘刷新增加 single-flight 和请求合并：
  • 同一时间只允许一个菜单构建任务运行。
  • 运行期间的多个刷新请求合并为一次后续刷新。
  • 后续刷新重新读取最新状态，避免旧快照覆盖新菜单。

复现方式

使用独立测试配置生成 3,000 个合法 Provider 文件，每个文件约 256 KiB，总大小约 788 MB。

文件只包含合成测试数据，不包含真实账号或凭据。该负载用于稳定放大同步 I/O 阻塞，便于捕获变更前后的首帧差异。

测试结果

变更前

• 隔离窗口约 59 ms 后被发现。
• 首次截图请求耗时约 1,342 ms。
• 从开始采样到截图完成约 1,427 ms。
• 捕获到的首帧为完整白屏。

变更后

• 隔离窗口约 67 ms 后被发现。
• 首次截图请求耗时约 298 ms。
• 从开始采样到截图完成约 392 ms。
• 首帧已经完整渲染，未再捕获到白屏。

截图

变更前：窗口首帧白屏

变更后：窗口首帧正常渲染

验证

• cargo fmt --check
• 托盘刷新协调测试：4 通过
• Rust 全量测试：428 通过，3 ignored
• cargo clippy --all-targets -- -D warnings
• 桌面 TypeScript/Vite 生产构建
• Windows 隔离环境高负载首帧复测

影响范围

本次修改针对 Provider 同步 I/O 导致的界面线程阻塞，不代表已经解决所有可能由 WebView 或窗口生命周期引起的本地白屏问题。