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
(now the published 0.4.3 release — see "Dependency update" below) 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.

Dependency update: prefix-safe-json 0.4.3 (security release)

prefix-safe-json moved 0.0.1-alpha.4 → 0.2.0 → now the published exact
0.4.3 (package.json updated to "0.4.3"; package-lock.json regenerated
with npm install prefix-safe-json@0.4.3 --save-exact, not hand-edited).

0.4.3 is a security release (GHSA-3xpw-9694-2xxp) fixing three root causes in
the AI SDK adapter/gate this integration depends on:

1. AiSdkStreamAdapter.push() used to silently drop every raw event once it
   had already observed its own terminal, so late/contradictory evidence for
   a call never reached the coordinator at all.
2. takeDecision() used to read a decision snapshot frozen at finish()
   time instead of the coordinator's live diagnostics, so evidence recorded
   after finish() but before that call's authority was consumed was never
   consulted.
3. A raw event carrying conflicting id/toolCallId used to silently
   prefer id instead of failing the stream closed.

No public API change: createAiSdkExecutionGuard() / push() / finish() /
takeDecision(), and the ExecuteDecision/NonExecutableDecision fields
this integration reads (action, toolCallId, reason), are unchanged —
confirmed directly against the installed package's .d.ts, not assumed.
0.4.3 still declares engines.node: >=18.0.0.

Does this integration's own code actually exercise the fix?
resolvePendingExecutions() in execution-guard.ts reads decisions
directly off guard.finish()'s own return value in the same statement — it
never calls takeDecision(). A fresh guard is created per step
(agent-loop.ts, inside the step loop) and is never reused once its
finish() is read, so there is no async gap between this integration's own
finish() call and its own decision consumption for GHSA-3xpw-9694-2xxp's
literal finish()-to-takeDecision() window to open in here. What is live is
root cause #1: whether a late/contradicting raw event arriving before a
step's own resolvePendingExecutions() call — anywhere in that step's
fullStream — correctly revokes authority instead of being silently
dropped by the adapter. New test:
src/__tests__/unit/execution-guard-post-terminal-authority.test.ts proves
this directly through this repo's real execution-guard.ts functions (the
exact call path agent-loop.ts uses), plus a control case confirming the
fix does not overcorrect a genuinely clean step, plus a second test against
the raw prefix-safe-json library directly (real push/finish/
takeDecision, no synthetic decision object) confirming the literal
advisory scenario is fixed at the library level.

Testing

• src/__tests__/unit/execution-guard.test.ts: 16/16 passing against
  the real 0.4.3 install
  • 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
• src/__tests__/unit/execution-guard-post-terminal-authority.test.ts
  (new): 3/3 passing — see "Dependency update" above
• npx tsc --noEmit (full project, real 0.4.3 install): clean, 0 errors
• npx eslint on every changed file: 0 errors, 0 warnings
• npm run test:harness-boundary: passing
• npm run build: passing
• Targeted relevant existing suites — every agent-loop-*, permission-*,
  tool-history-integrity, cli-tools-mcp, and execution-guard* file
  (19 files, 354 cases): 316 passing, 38 failing. Proved, not assumed,
  that all 38 are pre-existing and unrelated to this change: ran the
  identical 19-file suite against this same branch with the dependency
  bump and the new test file stashed out (i.e. the unmodified prior commit),
  and diffed the two failure lists — byte-for-byte identical set of 38/50
  failing cases in both runs (diff empty). All failures cluster in
  permission-registry/permission-approval-token/permission-profile-*/DB
  persistence tests (HMAC token verification, SQLite roundtrips) — none in
  execution-guard*, cli-tools*, or agent-loop* proper — consistent
  with the native-binding/DB sandbox limitation this PR's main history
  already documented (see prior "Dependency update" note on 0.2.0,
  now folded into this section).

Rebase

Rebased onto current main (26 commits ahead at rebase time, none touching
this PR's files — clean rebase, no conflicts).

[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 较大（9 个文件 / 1113 行改动；阈值 25 文件 / 800 行）。

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

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

[canblmz1]

recheck

[canblmz1]

Updated the integration from the old alpha build to the published prefix-safe-json 0.2.0 release and reran the execution-integrity tests. No architecture change; this only removes the prerelease dependency.