[FEATURE]: allow task subagents to run in a caller-selected directory

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Add an optional directory or worktree parameter to the task tool and propagate that resolved execution context to the child session, prompt loop, and all of its tools.

Today, task creates the child session inside the parent's InstanceState.context, so a subagent cannot operate in a linked worktree or another monorepo project without moving the entire parent session. The plugin hook also receives no per-Task execution directory that it can propagate.

This is not only a monorepo convenience. Provider-bound review tooling needs to keep an immutable candidate in worktree B while a parent orchestrator session runs from checkout A. Without per-Task context, the child tools run in A and cannot safely inspect B.

Required behavior:

• The new parameter is optional; omitting it preserves today's behavior.
• OpenCode resolves and validates the target directory before creating the child session.
• The child session, model/agent resolution, prompt, skills/AGENTS.md discovery, permissions, and every child tool execute in the resolved context.
• Plugin hooks can observe the resolved Task context rather than only the parent session context.
• Cross-project and cross-worktree use must remain explicit and permission-bounded.

Proposed minimal shape:

task({
  subagent_type: "review-reliability",
  description: "Review frozen candidate",
  prompt: "...",
  directory: "/absolute/path/to/worktree-B",
})

The binding must not be a shell-only cwd override. The child's file tools, LSP, permission checks, repository instructions, and plugin hooks must all see the same resolved context.

OpenCode v1.18.18 still has no such parameter in packages/opencode/src/tool/task.ts, and packages/plugin/src/index.ts exposes no per-Task cwd in tool.execute.before.

This is a renewal and narrower runtime-integrity use case for #29271, which was automatically closed after inactivity with the instruction to open a new issue if still relevant.