fix(cli): keep subagents running after permission denial

[marius-kilocode]

What Problem This Solves

Denying a tool permission inside a subagent, such as a read of .env, stops the entire child loop before it can finish exploration or return its findings. The parent can receive an empty task result and repeat the work.

Why This Change Was Made

The processor treats a rejected tool call as a session stop signal. Limit that stop behavior to root sessions. A child still records the denied tool as an error, but gets another model turn to use permitted tools and report its findings. This is a one-line runtime change; permission rules, root-session continuation settings, question dismissal, and cancellation are unchanged.

User Impact

Deny access to a file without losing the subagent exploration. The denied operation is not allowed, retried, or replaced with a successful result by the runtime.

Evidence

• Reproduced before the fix with the real prompt, task, read, and permission services: the child completed its first read, hit a rejected .env read, and never reached the next permitted read.
• The regression now passes and checks that the parent receives the child summary and the denied file contents never reach model requests. Two root-session cases preserve continue_loop_on_deny behavior.
• 87 relevant tests and CLI typecheck pass. Scoped lint reports only existing warnings; the annotation and whitespace checks pass.
• A live source backend with a scripted local provider confirmed the same flow through the public HTTP API: reject .env, complete the next permitted read, return findings to the parent. The dummy secret was absent from all provider requests. No real credentials or model calls were used.

Manual check: deny a subagent .env read, then confirm it continues with permitted files and returns a summary.

VS Code self-test

Reproduced both versions in the real sidebar with a disposable workspace, isolated VS Code profile, isolated Kilo storage, and a local scripted provider. The model responses were scripted; the task tool, permission dialog, Deny button, session loop, and returned task results were real.

• Before: click Deny for the child .env read. The child stops after two read attempts and the parent receives an empty task result.
• After: click Deny for the same read. The child completes the next permitted after.txt read and returns its findings. The dummy secret is absent from all provider requests.
• SHA-256 hashes of the normal Kilo config files and VS Code user settings are unchanged. The isolated instance and its temporary VS Code profiles were cleaned up.

Before / after: