test(desktop): prove the first verified-result journey

English

Parent roadmap: #2469 Completed prerequisite: #2497

Problem

Maka now has shared task-submission readiness in Core, Desktop, and CLI, but the Desktop suite does not prove that a ready user can continue through one coherent first-result journey. Existing tests separately cover sending, Git review, terminal results, and generated files; no behavior test connects task submission to a real project change, visible validation evidence, and user review.

A green send test is not enough: the user needs evidence that Maka changed the intended project, validation ran, and the result can be inspected without reading raw implementation state.

Scope

Add one deterministic vertical Desktop journey using the real Electron, Runtime Host, Session storage, project selection, transcript, and Git review paths. The isolated E2E backend may perform a narrowly named fixture task, but the product projections and UI must remain production paths.

Journey:

1. boot with a usable isolated model connection and Git project;
2. submit one small file-change task through the production composer;
3. persist a real file change in the isolated project;
4. publish structured file-diff and terminal-validation evidence through the Session event path;
5. complete the turn;
6. open Review from the session workbar and inspect the actual Git change;
7. record the bounded journey duration for CI diagnostics.

Acceptance criteria

• One Playwright test drives the journey through a real Electron window.
• Submission uses the production readiness and composer path.
• The task changes a real file inside an isolated Git project.
• The transcript shows structured successful validation evidence, not only an assistant claim.
• Review reads the real Git workspace and exposes the changed file/diff.
• The journey records elapsed time and remains within the existing E2E timeout.
• Fixture behavior is explicit, isolated, and unavailable outside E2E.
• No new top-level module, persisted authority, or decorative status model is introduced.

Non-goals

• Calling a paid external model in required CI.
• Building Completion Packet or the Phase 2 task-status header.
• Adding product telemetry or a metrics dashboard.
• Redesigning onboarding, Review, or the workbar.

---

父级路线：#2469 已完成前置：#2497

问题

Maka 已在 Core、Desktop 和 CLI 建立共享任务提交 readiness，但 Desktop 测试仍未证明：一个已经准备好的用户，能够沿同一条流程得到首次可验证结果。现有测试分别覆盖发送消息、Git 审阅、终端结果和生成文件，却没有把任务提交、真实项目改动、可见验证证据和用户审阅连成一条行为测试。

仅证明“消息发送成功”不够。用户还需要确认 Maka 修改了正确项目、运行了验证，并且无需理解内部状态就能检查结果。

范围

新增一条确定性的 Desktop 垂直旅程，使用真实 Electron、Runtime Host、Session 存储、项目选择、对话记录和 Git Review 路径。隔离 E2E backend 可以执行一个命名明确的 fixture 任务，但产品投影和 UI 必须走生产路径。

旅程：

1. 使用可用的隔离模型连接和 Git 项目启动；
2. 通过生产 composer 提交一个小文件修改任务；
3. 在隔离项目中产生真实文件变化；
4. 通过 Session event 路径发布结构化文件差异和终端验证证据；
5. 正常完成本轮；
6. 从会话 workbar 打开 Review，检查真实 Git 变化；
7. 记录旅程耗时，供 CI 诊断。

验收标准

• Playwright 通过真实 Electron 窗口驱动完整旅程。
• 提交经过生产 readiness 和 composer 路径。
• 任务在隔离 Git 项目中修改真实文件。
• 对话展示结构化的成功验证证据，而不是只有 Agent 自述。
• Review 从真实 Git 工作区读取并展示变更文件和 diff。
• 记录旅程耗时，并保持在现有 E2E timeout 内。
• Fixture 行为显式、隔离，并且在 E2E 之外不可用。
• 不新增顶级模块、持久化权威或装饰性状态模型。

非目标

• 在必跑 CI 中调用付费外部模型。
• 本次不构建 Completion Packet 或 Phase 2 task-status header。
• 不增加产品埋点或指标看板。
• 不重设计 onboarding、Review 或 workbar。