Windows Maven：依赖树不应依赖整段控制台输出，复用上游结构化依赖模型 #890

问题

Windows Maven 工具窗口加载依赖时出现 Maven dependency output exceeded the supported limit.。当前实现调用 maven-dependency-plugin:3.8.1:tree -Dverbose=true，累计整个进程输出，再交给 Rust Core 解析；平台捕获层和 Core 都限制为 500,000 字符。正常的大型项目也会因此无法查看依赖。

本 issue 用于后续根本修复，当前用户仅要求 Windows。macOS 平台代码不在本次范围内；共享契约变化仍需保持其他消费者兼容。

已确认的证据

• rust/lithe-core/src/project/maven.rs：dependency_plan 生成 CLI 命令，dependencies 解析整段文本。
• windows/tauri/src/features/maven/stores/maven.store.ts：appendDependencyOutput 累积日志，超限直接终止查询。
• 命令已有 -B -ntp，因此仅关闭下载进度不能解决大型树超限。
• 可复现数据：对 i = 0..5999 生成 [INFO] +- org.example.application.platform.dependencies:library-{i}:jar:1.0.0:compile (version managed from 0.9.0) ，仅 6,000 个节点就产生 694,890 字节的 ASCII 文本，超过旧限制，但仍低于已有 10,000 节点上限。
• 普通日志、版本冲突说明和树缩进共用同一文本预算；Windows 与 Core 原先的字符计数单位也不同。

当前临时处理（仅本地，尚未提交/合并）

依赖捕获预算改为 Core 下发的 8 MiB UTF-8 字节数，Windows 分块计数，保留超限停止、重试重置、取消、超时、节点数和深度保护。该补丁用于临时恢复使用，仍依赖整体 CLI 文本，因此不能作为本 issue 的根本解决方案。

临时补丁的验证包括 6,000 节点完整性、精确字节边界、多字节超限、迟到事件和重试。Windows Release 构建、104 项 Maven 前端测试、62 项 Maven 相关 Core 计时测试、158 项 Windows 原生测试通过。这些是合成/自动化验证，不等于用户项目已经完成端到端复现。

建议调查方向

先检查现有 Java 后端（JDT LS/m2e）的版本、公开扩展能力以及能否返回完整依赖图，优先复用已持有项目事实的上游模型，不在 Lithe 中再维护独立解析器/解析状态。如果它无法提供所需完整树，应记录缺口，再评估成熟 Maven Resolver/项目导入子系统的集成，或具有明确日志隔离和生命周期的结构化插件输出方案。

IDEA Community 的参考实现通过 Maven 组件和结构化项目模型组织依赖，不把整个控制台文本作为依赖树来源：

• Maven36ServerEmbedderImpl
• MavenProject.kt 中的 dependencies / dependencyTree

参考其边界和成熟上游能力即可，不预设直接搬入整个 IDEA 插件。依赖语义归上游，Lithe 负责调度、取消、资源预算、过期结果隔离及展示。

验收要求

• 合法的大型依赖树不再因普通控制台日志量而失败；日志与依赖数据分离。
• 保留模块归属、作用域、版本管理、重复依赖和版本冲突信息；不能把扁平 classpath 当成完整依赖树。
• 保持项目 Maven/mvnd、settings、profiles、本地仓库及 JDK 选择的一致性。
• 依赖刷新、配置变化、取消/超时、进程退出和重试形成完整流程；拒绝迟到结果，无进程/临时文件泄漏。
• 不允许通过截断数据后显示成功、取消资源保护或持续增大固定上限来关闭本 issue。
• 补充真实大型项目验证及确定性的自动化回归测试，记录性能/内存开销、协议和 Agent Note。