isolation: "worktree" on the Agent tool does not sandbox absolute file paths — sub-agent can write outside its pinned worktree

When launching a sub-agent with isolation: "worktree", the harness creates a dedicated git worktree and starts the agent there, but this only pins the agent's default working directory — it doesn't appear to block Edit/Write calls that pass an absolute file_path pointing outside that worktree (e.g. back at the main checkout or another worktree).

Observed in practice: a sub-agent launched with isolation: "worktree" hardcoded the main checkout's absolute path instead of deriving paths from its actual cwd, and its Edit/Write calls succeeded against the main checkout — no rejection, no warning. It self-corrected only because it happened to run git status and noticed unexpected changes there, then manually stashed and reapplied them in the correct worktree before committing.

This is inconsistent with the enforcement that does exist for a session's own pinned worktree — e.g. a top-level session that calls EnterWorktree gets shell cd attempts back to the shared checkout silently reset, and file edits in the shared checkout are documented as being rejected until isolated. That protection doesn't seem to extend to sub-agents launched via isolation: "worktree" when they pass an absolute path outside their pin.

Impact: In a multi-agent workflow (e.g. several sub-agents each working an isolated GitHub issue in parallel), a sub-agent that gets a path wrong can silently write into another worktree or the shared main checkout, colliding with concurrent work — exactly the class of bug worktree isolation is meant to prevent. It happened to be caught by chance this time, not by the system.

Suggested fix: When an agent is launched with isolation: "worktree" (or any pinned-cwd isolation), validate that Edit/Write/Bash file-affecting paths resolve inside the pinned worktree, and reject (or resolve relative-to-pin) paths that escape it — mirroring the existing shared-checkout rejection behavior.