fix(cli-tools): defer install execution until step completion is confirmed

[canblmz1]

Problem

codepilot_cli_tools_install executes execAsync(command, ...) as soon as the
AI SDK resolves that individual tool call.

At that point, the tool itself has no visibility into whether the surrounding
generation later terminates safely. A syntactically complete tool call can still
belong to a step that ends because of a token limit, provider error, or another
unsafe terminal condition.

The existing permission system does not currently carry stream-completion
state, so it cannot make an execution-integrity decision based on whether the
surrounding generation terminated safely.

Reproduction

src/__tests__/unit/execution-guard.test.ts covers a
codepilot_cli_tools_install call whose own arguments are complete, followed by
a step ending with finishReason: "length".

The contrast case demonstrates the previous execution pattern: once
execute() is entered, the real command runs without any knowledge of the
step's final termination state.

Fix

This patch uses
prefix-safe-json
0.0.1-alpha.4 and its createAiSdkExecutionGuard() API to gate the real side
effect using the raw fullStream parts already consumed in agent-loop.ts.

The real install command cannot wait inside the tool's execute() for the
stream's terminal state, because the stream cannot finish until in-flight tool
executions resolve.

Instead:

1. codepilot_cli_tools_install.execute() registers the real install closure
   and immediately returns a queued result.
2. agent-loop.ts feeds the step's raw fullStream events into the execution
   guard.
3. Once the stream is fully consumed, each pending execution is resolved
   against the guard decision for its toolCallId.
4. The real execAsync side effect runs only when the surrounding tool call is
   positively confirmed safe to execute.

The scope is intentionally narrow: only
codepilot_cli_tools_install, the directly shell-executing tool traced in this
patch, is converted. Other execute()-based tools may benefit from the same
pattern, but are intentionally out of scope here.

Safety semantics

A real install command executes only when the surrounding streamed tool call is
positively confirmed complete.

Truncated, errored, unknown, or otherwise unconfirmed terminal states discard
the pending side effect instead of executing it.

Follow-up fixes (turn isolation + model-history correctness)

Two issues found in review of the first commit, addressed in a second commit
on this branch:

Deferred state is isolated per Native turn, not by toolCallId alone.
toolCallId is provider-generated per call and not guaranteed unique across
concurrent turns — two overlapping turns can both produce e.g. "call_1"
(the same identity-isolation concern runtime/native-turn-registry.ts
already handles for abort controllers, for the same underlying reason). A
fresh executionScopeId is created once per runAgentLoop invocation and
threaded through the existing tool-assembly chain
(agent-loop.ts → assembleTools → getBuiltinTools →
createCliToolsTools), so pending registrations are keyed by
scope + toolCallId and two turns can never resolve or discard each other's
pending commands even if their toolCallIds collide.

Abort/error cleanup discards pending closures fail-closed. Every step
already resolves its own scope's registrations; a new
discardPendingExecutions(scopeId) is additionally called from
agent-loop.ts's teardown finally block (which runs on every exit path —
success, abort, timeout, thrown error), so a turn that never reaches its own
step-level resolution can never leave a queued shell command available for a
later, unrelated turn to accidentally resolve. Any registration left
unmatched by a guard decision at step-resolution time is discarded the same
way, not carried forward.

The real deferred result now replaces the temporary "Queued…" placeholder
in the next model-step transcript, not just the UI. The AI SDK bakes
execute()'s immediate "Queued…" return value into responseData.messages
as that call's tool-result — which is exactly what gets appended to the
conversation for the next step. Previously only a follow-up SSE event told
the UI the real outcome; the model's own history permanently kept
"Queued…" as the result. applyResolvedExecutionsToMessages() now replaces
that placeholder with the real outcome (the actual result text for an
executed call, or an explicit "Execution skipped: …" message — never a
claimed success — for a rejected one) before the messages are appended,
using the repository's existing ModelMessage tool-result shape from
tool-history-integrity.ts. Only the matching toolCallId's part is
touched; every other message and part is unchanged. The UI SSE and the
model transcript now share the exact same outcome text, so they can never
disagree about what happened.

Scope is unchanged from the first commit: only Native Runtime's
codepilot_cli_tools_install is affected, and cli-tools-mcp.ts (the SDK
Runtime's independent implementation) is not touched.

Testing

• src/__tests__/unit/execution-guard.test.ts: 16/16 passing
  • safe tool-calls completion → executes exactly once
  • finishReason: "length" → does not execute
  • truncated arguments → does not execute
  • provider error → does not execute
  • unknown terminal state → does not execute
  • unrelated unregistered tool call → ignored
  • contrast case confirms the previous unconditional execution pattern would
    run in the same length scenario
  • two scopes registering the identical toolCallId never cross-resolve,
    even resolved in adversarial order
  • a discarded scope's closure never runs, even when a later, unrelated
    scope reuses the same toolCallId
  • a registration left unmatched by any guard decision is discarded, not
    carried forward
  • applyResolvedExecutionsToMessages: the safe case never leaves "Queued"
    in the transcript and shows the real result; the unsafe case never
    leaves "Queued" and never claims success; an unrelated tool-result
    message is returned byte-identical; only the matching toolCallId
    among multiple parts in one message is replaced
• npx tsc --noEmit: clean
• npx eslint on every changed file: 0 errors; the one new warning
  introduced during review was fixed, the remaining warnings in
  agent-loop.ts are pre-existing (confirmed identical against the
  unpatched file) and unrelated to this change
• Targeted relevant existing suites (agent-loop-*, agent-tools-permission-allowlist,
  cli-tools-mcp, tool-history-integrity): 128/131 passing; the 3 failures
  are better-sqlite3's native binding missing in this sandbox (confirmed
  reproducible identically with the patch stashed), unrelated to these changes
• Full unit-suite execution in this sandbox has the same known
  better-sqlite3 native-binding limitation described above

prefix-safe-json@0.0.1-alpha.4 was installed from the public npm registry
(unchanged from the first commit).

[vercel]

Someone is attempting to deploy a commit to the op7418's projects Team on Vercel.

A member of the Team first needs to authorize it.

[github-actions]

⚠️ 这个 PR 较大（8 个文件 / 814 行改动；阈值 25 文件 / 800 行）。

建议拆分成更小、聚焦的 PR，或在描述里说明为什么需要一次性改这么多——这样更好审查、风险更低。

这只是提醒，不阻塞合并。

[canblmz1]

recheck