feat(web-shell): adopt canonical Goal v3 controls

[qqqys]

What this PR does

This PR adopts the canonical Goal v3 control plane in WebShell. Goals can be created before the first chat message, inspected, edited, paused, resumed, replaced, and cleared without routing commands through the model. WebShell presents the active Goal in a compact composer row, keeps that row at the queued-message width, and removes the delete confirmation.

While a Goal is running, ordinary messages remain in a local FIFO queue. They are submitted normally after the Goal stops; only the explicit Insert action enters the active turn. The change also exposes typed Goal state and controls through the daemon, SDK, ACP bridge, and shared WebUI data layer so WebShell has one canonical source of truth.

The TUI keeps its existing visual style and command flow. Token-budget UI and desktop-shell adoption are intentionally excluded.

Why it's needed

The previous WebShell behavior mixed Goal commands with chat prompts, required a conversation before setting a Goal, and allowed queued messages to interrupt autonomous execution unexpectedly. Goal state also had multiple UI-owned interpretations, which produced transient load errors and inconsistent lifecycle rendering.

The canonical control path makes Goal lifecycle changes deterministic, lets a new task start directly with /goal, preserves queue intent, and gives all consumers the same revisioned Goal snapshot.

Reviewer Test Plan

How to verify

1. Open a new WebShell task with no existing session, submit /goal <objective>, and confirm a session is created with an active Goal while no ordinary chat prompt is sent.
2. From the compact Goal row, edit the objective, pause, resume, and clear it. Confirm state and elapsed time update, edits use the current Goal identity/revision, and clear does not open a confirmation dialog.
3. While the Goal is running, send a normal message. Confirm it remains queued and does not interrupt the current turn. Choose Insert and confirm only that explicit action enters the active turn.
4. Queue another message and pause or clear the Goal. Confirm the held messages drain through the normal prompt path in FIFO order.
5. Compare the active Goal row with a queued-message row and confirm the Goal keeps the same width while the composer remains unchanged.
6. Run the TUI Goal flow and confirm its existing presentation supports create, status, edit, pause, resume, completion, and clear without visual redesign.

Automated browser coverage runs the complete fresh-session and active-Goal queue chains. A separate PR comment contains the E2E scenario report and captured evidence inventory.

Evidence (Before & After)

Before: WebShell treated Goal setup as part of chat/session state, could require an initial message, used independently sized Goal and queue rows, and could feed ordinary queued messages into the running turn.

After: /goal can allocate its own session, the compact Goal row matches the queued-message width, normal messages remain locally queued, explicit Insert is the only mid-turn path, and clear is immediate. TUI remains visually unchanged and was exercised through three tmux chains.

Tested on

OS	Status
🍏 macOS	✅
🪟 Windows	⚠️
🐧 Linux	⚠️

Environment (optional)

Node.js 22.17.0, local source build, Chromium Playwright against the WebShell daemon harness, and a 140x42 tmux TUI session without sandboxing.

Risk & Scope

• Main risk or tradeoff: Active-Goal messages now remain in WebShell memory until the Goal becomes inactive, so closing the page before submission discards those local queued messages, matching the existing local composer queue boundary.
• Not validated / out of scope: Desktop-shell styling, token-budget UI, Windows/Linux manual UI testing, and changes to the TUI visual design.
• Breaking changes / migration notes: No public CLI migration is required. Older daemons remain readable; mutation-only controls such as Insert are hidden when the canonical control capability is unavailable.

Linked Issues

N/A

中文说明

本 PR 做了什么

本 PR 在 WebShell 中接入 canonical Goal v3 控制面。无需先发送聊天消息即可创建 Goal，并可直接查看、编辑、暂停、恢复、替换和清除，不再把这些命令发送给模型。WebShell 在输入框上方展示紧凑的 Goal 状态条，保持排队消息的宽度，同时删除 Goal 时不再弹出确认框。

Goal 运行时，普通消息保留在本地 FIFO 队列中；Goal 停止后再按正常消息发送。只有用户明确点击“插入”时，消息才会进入当前执行轮次。本次还通过 daemon、SDK、ACP bridge 和共享 WebUI 数据层暴露统一的 Goal 状态与控制能力，让 WebShell 使用同一份 canonical 状态。

TUI 保持现有视觉风格和命令流程。本 PR 不包含 token 预算 UI 和桌面端接入。

为什么需要

此前 WebShell 会把 Goal 命令和聊天消息混在一起，设置 Goal 前可能需要先创建会话；排队消息也可能意外中断自治执行。Goal 状态还存在多套 UI 侧解释，造成过瞬时加载错误和生命周期展示不一致。

canonical 控制路径让 Goal 生命周期变更更确定，支持新任务直接从 /goal 开始，保留用户的排队意图，并让所有消费者读取同一份带版本的 Goal 快照。

Reviewer Test Plan

验证方式

1. 在没有会话的新 WebShell 任务中提交 /goal <目标>，确认系统创建会话并激活 Goal，同时没有发送普通聊天消息。
2. 使用紧凑 Goal 状态条编辑目标、暂停、恢复和清除，确认状态和耗时更新，编辑携带当前 Goal 身份与 revision，清除时没有确认弹窗。
3. Goal 运行时发送普通消息，确认消息保持排队且不会中断当前轮次；点击“插入”后，确认只有这次明确操作进入当前轮次。
4. 再排队一条消息，然后暂停或清除 Goal，确认保留消息按照 FIFO 顺序通过正常 prompt 路径发送。
5. 对比 Goal 状态条和排队消息，确认 Goal 保持相同宽度且输入框布局不变。
6. 在 TUI 运行 Goal 链路，确认现有视觉下的创建、查看、编辑、暂停、恢复、完成和清除均正常，没有视觉重做。

自动化浏览器用例覆盖首次创建会话和运行中 Goal 排队的完整链路。PR 的独立评论附有 E2E 场景报告与截图证据清单。

前后对比证据

Before：WebShell 的 Goal 设置依赖聊天/会话状态，可能要求先发送消息；Goal 与排队消息宽度独立；普通排队消息可能进入正在执行的轮次。

After：/goal 可自行分配会话，紧凑 Goal 状态条保持排队消息宽度，普通消息继续本地排队，只有明确点击“插入”才进入当前轮次，清除操作立即生效。TUI 视觉保持不变，并通过三条 tmux 链路验证。

测试平台

系统	状态
🍏 macOS	✅
🪟 Windows	⚠️
🐧 Linux	⚠️

环境

Node.js 22.17.0、本地源码构建、Chromium Playwright WebShell daemon harness，以及 140x42 无沙箱 tmux TUI 会话。

风险与范围

• 主要风险或权衡：Goal 运行时的消息保存在 WebShell 内存中，提交前关闭页面会丢失这些本地排队消息，这与现有输入框本地队列边界一致。
• 未验证/不在范围内：桌面端样式、token 预算 UI、Windows/Linux 手工 UI 验证，以及 TUI 视觉调整。
• 破坏性变更/迁移说明：不需要公开 CLI 迁移。旧 daemon 仍可读取；当 canonical 控制能力不可用时，Insert 等仅变更状态的控件会隐藏。

关联 Issue

N/A