fix(core): keep sub-commands after a state planter in the confirmation scope - #10030

What this PR does

Stops the shell confirmation dialog from showing less than what it runs.

The dialog is built by splitting a compound command and dropping the parts that classify read-only, so the user approves only what needs approving. That is sound only while each part means the same thing alone as it does in sequence — and after a cd, an export, or a hash -p it does not. cd /hostile && git status && npm run build showed the user npm, dropped git status as independently read-only, and then executed the whole original compound, git status included, in the planted directory. Approval covered a command the dialog never displayed.

Both call sites — ShellTool and MonitorTool — now stop dropping sub-commands once an earlier one has planted state, mirroring what PermissionManager.evaluateCompoundCommand already does. The planter is decided before its own drop decision and is never dropped itself: cd /hostile classifies read-only on its own, and it is precisely the segment the user most needs to see. The gate also covers the allow-rule path, since a Bash(git *) rule matches on a sub-command's own text, which after a cd no longer says where it runs.

Whether a segment plants is decided on the parse, not the raw text. A leading-word regex cannot be completed here: the planter hides behind a block ({ cd /hostile; }), a keyword (if true; then cd /hostile; fi), an assignment prefix (FOO=1 cd), a resolution-order prefix (command -p cd), a respelling (\cd, "cd"), a negation (! cd), or a function definition that rebinds a trusted name (git() { rm -rf $HOME; }) — and a bare PATH=evil assignment carries no command word at all. So only a plain command node whose resolved name is not a planter is cleared, and every other shape fails closed. That costs a larger dialog, never a silently narrowed one.

The planter set covers the builtins that rebind what a later command resolves to or reads: the cd/export family, the assigning builtins (read, mapfile, readarray, getopts, printf -v), and the resolution-rebinding ones (hash, alias, unalias, trap, enable, fc, shopt, let, exec). A substitution in a redirect target plants too: echo x < $(./evil.sh) runs the script before anything after it is classified.

Why it's needed

This is an approve-what-wasn't-shown bug. execute() runs this.params.command — the full original string — while the dialog is assembled from a filtered subset. Any gap between the two is a command the user authorised without seeing, and the gap is reachable with a single cd.

Reviewer Test Plan

How to verify

cd packages/core && npx vitest run src/utils/shellAstParser.test.ts src/tools/shell.test.ts src/tools/monitor.test.ts

 Test Files  3 passed (3)
      Tests  936 passed (936)

Behavioural check, before this change on main — build a ShellToolInvocation for cd /repo2 && git status && npm run build and read getConfirmationDetails():

• Before: rootCommand is npm. git status and cd are both gone.
• After: rootCommand is cd, git, npm.

The drop itself is intact for segments that mean the same thing alone as in sequence — ls -la && npm run build still drops ls.

Mutation-verified on both sides: removing the statePlanted gate in shell.ts fails 1 test, in monitor.ts fails 2; removing the allow-rule guard fails 1; forcing the planter decision to false fails 3; and clearing every non-command shape in the predicate fails 1.

monitor.test.ts previously mocked the whole shellAstParser module; the mock now spreads importOriginal() so the confirmation scope runs against the real predicate — a stub returning false would hide the very defect these tests guard.

Note: src/permissions/permission-manager.test.ts has 2 failures on main at this commit (resolveToolName exhaustiveness (#9827), about ReportFindings). They are unrelated to this PR and reproduce on a clean origin/main checkout.

Evidence (Before & After)

The user-visible change is the content of the confirmation dialog's question line and its extracted permission rules, both asserted in shell.test.ts / monitor.test.ts as above. No layout or styling change.

Tested on

Risk & Scope

• Main risk: confirmation dialogs get longer. Any compound whose first segment is a planter now lists every later segment, including ones the user was used to seeing dropped. That is the intended direction — the dialog should not claim a smaller scope than it grants — but it is more clicking for cd x && <read-only thing>.
• Also: the predicate fails closed on anything it cannot parse or recognise, so an exotic-but-harmless segment will keep later ones in scope rather than drop them. Deliberate: over-showing is recoverable, under-showing is not.
• Not validated / out of scope: the pre-existing permission-manager failures noted above. isToolCallConcurrencySafe is untouched — it is a batching optimisation, not a permission decision.
• Breaking changes: none.

Linked Issues

No issue to close. This is a self-contained correctness fix carved out of #9950 — the confirmation-scope and state-planter gaps surfaced while that PR was under review, and they are filed separately so they can land on their own merits. Referenced without a closing keyword: #9950.