fix(sdk): validate nested apply_patch targets

[B-A-M-N]

Validate nested apply_patch targets

The execution policy must check the target nested in an apply_patch call's operation.path. This follow-up resolves that path against the project root before dispatch: in-project targets are allowed, and outside-project targets are rejected before the write override runs. The regression test explicitly grants external-tool trust so it verifies target confinement after host trust has been granted.

PR branch and scope

• Target base: upstream main
• Head branch: security/1450-apply-patch-target-review-r2
• Head: 6611d08c6d6a1017f9a7fa9e12b48d5183883fac
• Depends on #1506, whose updated head is 3cf2370efebb951527139963ec3501d208f9003c.
• Incremental diff from the feat(security): enforceable execution permissions for shell and filesystem access (#1450) #1506 head: 3 files, +59 / -8. Commits: 764e46286 target-path validation and 6611d08c6 trusted-override regression.
• Incremental compare.

GitHub does not support stacked pull requests across forks, so this follow-up targets upstream main; its displayed diff includes the prerequisite SDK change until #1506 is merged. The incremental compare above shows this follow-up's scope.

Verification

The complete stacked suite passed 98 tests across 9 files, including both apply_patch target tests. No typecheck diagnostic was reported in changed files.

Inference for this contribution was provided by FreeInference.org. FreeInference did not review, direct, approve, or otherwise participate in this work; all implementation, testing, and publication decisions are the contributor's own. If you find this useful, consider donating to FreeInference.org — they provide a useful and vital service.

[codebuff-team]

The core idea is sound: apply_patch's target lives in operation.path, not a top-level path, so a naive dispatcher could let --project-only be bypassed for patch operations. The fix in run.ts's handleToolCall (resolving operation.path before authorizing fs-write) and the regression test in apply-patch-target.test.ts are both clear and correctly scoped to that gap.

The problem is everything else. This PR's diff is +1488/-13 across 8 files, but the body says the actual incremental change versus PR #1506 is only 3 files / +59/-8. The rest — permissions/execution-policy.ts (408 new lines), authorizeToolCall, guardFileSystem, classifyTool, the README section on noShell/askShell/projectOnly/readOnly, and the 300+ line subagent-execution-policy.test.ts — belongs to #1506, which is not merged here. Since this mirror only accepts standalone, portable changes (each PR is hand-ported into a private tree), a maintainer can't tell what in this diff is new versus already reviewed elsewhere, and can't port "the apply_patch fix" without also re-reviewing an entire permission subsystem it depends on.

Please either:

1. Wait for feat(security): enforceable execution permissions for shell and filesystem access (#1450) #1506 to land and then submit only the incremental diff (the 3 files / +59/-8 you mention), or
2. If feat(security): enforceable execution permissions for shell and filesystem access (#1450) #1506 is unlikely to merge soon, inline just the minimal pieces of execution-policy.ts that apply_patch validation actually needs, with a title and diff that match in scope.

As submitted, this isn't reviewable as the "nested apply_patch" fix the title promises.