Feat/lsp 添加 LSP 面板，将 LSP 全部内容都整合到 Rust core 里面

[xiaoyumuxi]

该改动逻辑还没有进行闭环和测试，基础的功能仍有不稳定的情况，部分 LSP 的管线逻辑仍然耦合在 swift 的逻辑里面需要等待进一步的改善，后续主要是从解耦还有 LSP 的正常使用上面

[xiaoyumuxi]

目前审核出来还存在的问题：

1. JDT jdt:// 虚拟源码跳转存在类型契约问题：JDT LS 跳转到 JDK / dependency class 时，返回的不一定是 file://，可能是：jdt://contents/.../String.class Rust LSP 层目前对非 file:// location 会得到：filePath = null、isReadOnly = true
   但是 Swift BuiltinNavigationPayload.Location 中：filePath: String是非 Optional。因此 Rust → Swift JSON decode 时可能直接失败，导致 Java 跳转到 JDK / dependency source 无法正常工作。
2. LSP executable validation 会阻塞 MainActor：LanguageServerToolService 是 @mainactor。但目前 executable validation 内部直接同步调用：processRunner.run(...)单次 timeout 可以达到 5 秒。同时 LanguageServerSetupView 的 body / computed properties 会访问：candidates、executableVerificationState也就是说第一次进入 LSP 配置页或者 cache 失效时，有机会直接在 UI 主线程启动外部进程并等待结果。表现上可能就是：打开 LSP 设置 → UI 卡顿几秒。
3. Generic LSP Request 对 document lifecycle 绑定过重：
   现在这些请求：
   textDocument/completion
   textDocument/hover
   textDocument/rename
   completionItem/resolve
   codeAction/resolve
   workspace/executeCommand
   最后基本都经过统一的 requestFeature()。而 requestFeature() 会统一检查：openedDocumentURIs.contains(fileURL)这对于 textDocument/* 是合理的。但：
   completionItem/resolve
   codeAction/resolve
   workspace/executeCommand
   本身并不是标准的 textDocument request。
   特别是 workspace/executeCommand 不应该天然要求一个 document 必须处于 open 状态。

[xiaoyumuxi]

主要需要处理的就是彻底把实际 App LSP runtime 切到 engine.rs，然后删掉双轨实现。 这个一直因为同时跑两个LSP逻辑导致没有办法很好的去进行维护，我的移除一直不是很彻底