fix(cli): preserve approved shell commands across confirmation retries - #29201

Fixes #29197

What happened

When a TOML custom command contains multiple !{...} shell injections that each need confirmation, the CLI could get stuck asking for permission forever — cycling between commands, and never converging even if the user chose "always allow" for every prompt.

Root cause

FileCommandLoader's command action re-runs the entire prompt-processing pipeline from scratch on every retry. When ShellProcessor throws ConfirmationRequiredError, slashCommandProcessor.ts's confirm_shell_commands handler recurses into handleSlashCommand with a fresh one-time allowlist containing only the commands approved in that round:

return await handleSlashCommand(
  result.originalInvocation.raw,
  // Pass the approved commands as a one-time grant for this execution.
  new Set(approvedCommands),
  undefined,
  false,
);

If a second, distinct command still needs confirmation on the retry (e.g. discovered in a later part of the prompt), a second round begins. That round's one-time allowlist only contains the newly approved command — the one approved in the first round is dropped, because:

• it isn't in this round's approvedCommands, and
• the persisted sessionShellAllowlist React state update from the first round (setSessionShellAllowlist) may not have been reflected into the commandContext this in-flight recursive call closure is using yet, even when the user picked "Always".

So the command originally approved gets asked again, and this can cycle indefinitely.

Fix

Accumulate approvals across the whole confirmation chain instead of replacing them each round:

new Set([
  ...(oneTimeShellAllowlist ?? []),
  ...approvedCommands,
]),

Now every retry keeps every command approved so far in that chain, regardless of whether the backing React state has re-rendered yet, so the loop always converges once every distinct command has been confirmed at least once.

Testing

Added a regression test in packages/cli/src/ui/hooks/slashCommandProcessor.test.tsx ("Shell command confirmation > accumulates approvals across multiple confirmation rounds instead of looping forever") that simulates a command action which re-checks context.session.sessionShellAllowlist from scratch on each invocation and asks for cmd1 then cmd2 in turn.

• Confirmed the test fails against the pre-fix code: it hangs and times out after 60s because the third round asks for cmd1 again (reproducing the infinite loop).
• Confirmed the test passes with the fix: both confirmations resolve in two rounds.

$ npx vitest run src/ui/hooks/slashCommandProcessor.test.tsx
 ✓ src/ui/hooks/slashCommandProcessor.test.tsx (39 tests)
   ✓ useSlashCommandProcessor > Shell command confirmation > accumulates approvals across multiple confirmation rounds instead of looping forever

 Test Files  1 passed (1)
      Tests  39 passed (39)

Also ran:

• npx eslint src/ui/hooks/slashCommandProcessor.ts src/ui/hooks/slashCommandProcessor.test.tsx — clean
• npx tsc --noEmit (packages/cli) — clean
• npx vitest run src/services/prompt-processors/shellProcessor.test.ts — 34 tests passed (unaffected)

AI assistance disclosure

This PR was prepared with the assistance of an AI coding agent (Claude), including root-cause analysis, the fix, and the regression test. All changes were verified by running the project's real lint/typecheck/test commands as shown above.