feat(windows): add unified Maven tool window

[Mucheen]

依赖关系

Depends on #320. 本 PR 的 base 已设置为 feat/issue-291-macos-maven，且相对 #320 只包含 windows/。合并顺序为 #320 -> #321；#320 合并后再把本分支 rebase 到最新 preview。

Closes#291 after #320 is merged.

主要变更

• 新增 Windows Maven 工具窗口，展示根项目、递归模块、Profiles 和各模块 Lifecycle。
• 支持 Run Selected、双击 Lifecycle、自定义 Goal、Reload、Stop、Skip Tests、Collapse All 和 Maven Settings。
• Tauri Maven host adapter 负责本机 Maven/JDK 发现、结构化进程启动、输出事件、停止和本机配置持久化。
• Profiles、settings.xml、Maven executable 和 Maven JDK 与 Run/JDT LS 共用 feat(maven): unify shared Maven context and macOS tool window #320 的 Maven 上下文。
• React feature 只通过 @/platform/tauri-core 与 host 通信；Maven 参数全部由共享 Core Launch Plan 生成。

Review 修复

• MavenTaskStatus 增加 cancelled；停止成功和“退出事件先于 stop 返回”的竞态都会保留取消状态及输出，清空输出后恢复 idle。
• UI 增加中英文 Cancelled 文案。
• Windows Rust 消费共享 storage identity fixture，TypeScript 消费共享 lifecycle fixture。
• Run 编辑器新增“继承项目 / 运行测试 / 跳过测试”三态，显式 false 不会被 null 吞掉。
• 空工作目录发送空字符串，表示移除覆盖并继承项目默认值。
• 已还原 run.store.ts 中与 Maven 无关的 import、缩进和换行变化。

测试覆盖

• Maven Core/host API contract tests。
• Maven store 扫描、持久化、Launch、停止、取消竞态和旧结果隔离 tests。
• Run Core API 的 cwd 与 mavenSkipTests 三态 tests。
• JDT LS Maven context、Workbench item order 和共享 fixture 一致性 tests。

已执行验证

• TypeScript：tsc --noEmit 通过。
• Windows Tauri Rust Maven 测试组：3/3 通过。
• ./scripts/verify-shared-contracts.sh
• ./scripts/verify-windows-boundaries.sh
• ./.agents/skills/write-stable-tests/scripts/verify-test-stability.sh
• Rust format 与 git diff --check 通过。

尚未执行

本机没有 Parallels CLI 和 Bun，无法执行真实 Windows guest 的 timing lane 或 UI 手工验收。当前 Windows CI 会执行 Bun、Tauri Rust 和构建验证，本 PR 保持 Draft，待 CI 结果确认后再转 Ready。

[1lck]

Windows 这半边整体跟得挺齐：React 只通过 @/platform/tauri-core 走，参数一律来自共享 Core，maven.store.ts 里 launchRevision/diagnosticsRevision 那套旧结果隔离做得比较细，进程按 operation ID 停。工作区作用域的 store 拆分也对。

主要三条，都跟「两端对不齐」有关——这也是两个 PR 分开 review 的代价，单看任一个都是自洽的。

另外 #320 上我提了三个 Run 路径的回归（cwd 被覆盖、skipTests 没法覆盖、-am 写死），其中 cwd 那条在这边是必然触发的：run.store.ts 无条件传 currentMavenLaunchContext(root)，所以 Windows 上所有 Maven Run 配置的工作目录都会被 reactor 路径改掉。等 #320 修完 rebase 就好，这边不用单独动。

[1lck]

这个是草稿 在开发是吧 @Mucheen

[Mucheen]

对，还没开发完

[1lck]

Windows Maven 主体实现的分层方向是对的：React 通过 @/platform/tauri-core，Launch Plan 由共享 Core 生成，Maven store 也覆盖了旧结果隔离、取消竞态和配置写入串行化。现有 Windows CI、相关 Bun 测试和 Rust 测试均通过。

不过当前还有两处会破坏多项目 workspace 隔离的行为问题，因此这轮先 Request changes：

1. Java LSP 解析 Maven context 时丢失来源 workspace ID，后台预热/重启可能把 A 项目写进当前激活的 B store，并停止 B 的 Maven 任务。
2. Maven Reload 在 await 后重新读取当前激活 store，会把旧 root 和新 workspace 的文件/store 混用。

推荐不要继续依赖 workspaceRuntimeRegistry.getActiveWorkspaceId() 作为异步流程的隐式上下文。可以引入一个轻量的 WorkspaceLaunchScope（workspaceId + root），从 workspace 初始化、LSP owner、LSP client 一直传到 Maven context resolver；所有 await 后的读写都使用 getStore(scope.workspaceId)，并在执行 UI 或 LSP 副作用前校验 scope 仍有效。这样 Run、Maven 和 JDT LS 三条路径会共享同一种 workspace 所有权模型。

建议补两组确定性回归测试：

• 激活 B 时为 A resolve/restart Java LSP，断言只更新 A 的 Maven store，B 的 project、activeSessionId 和输出保持不变。
• A 点击 Reload 后挂起 scan，切到 B 再完成 scan，断言不会读取或修改 B 的 Maven/FileSystem store，也不会用 B 的 Java 文件 prewarm A。

另外活动栏的可见性菜单和 workbench.maven 中英文文案还没有接完整，详见 inline comments。前两项修复并补测试后，这个 PR 的整体质量就比较稳了。