delegate_task: run the child in another project or worktree on the same environment

[niieani]

Problem

An orchestrating thread can't hand work to a nested child that runs somewhere other than its own checkout.

• delegate_task creates a proper child: it has a parent, wakes the parent on completion, and is hidden from the sidebar. But the child always inherits the parent's projectId, branch and worktreePath (makeSubagentChildThread in packages/provider-core/src/server/subagentProjection.ts spreads ...input.parentThread).
• t3_thread_launch can target any project and a new or existing worktree, but always creates a top-level thread (dispatchThreadCreate in apps/server/src/orchestration-v2/Orchestrator.ts writes parentThreadId: null). There's no wake-up, and the thread lands in the sidebar.

Our use case: an orchestrator thread in one repo (a notes vault) coordinates implementation work in other repos on the same machine. Each piece of work runs in its own worktree of the target repo and is reviewed before merging. Today every such child becomes a top-level thread, and the orchestrator has to poll for completion.

#16719 adds target.projectId for linked environments, but explicitly refuses a local target.projectId that names another project.

Proposal

Add optional projectId and workspaceStrategy to delegate_task, reusing OrchestrationV2ThreadLaunchWorkspaceStrategy:

• packages/contracts/src/orchestratorMcp.ts: add both fields to the input.
• packages/contracts/src/orchestrationV2.ts: add them to the delegated_task.request command.
• OrchestratorMcpService.delegateTask: resolve the project with resolveProjectTarget and assertLiveCallerForOtherProject.
• dispatchDelegatedTaskRequest and makeSubagentChildThread: override projectId, branch and worktreePath instead of copying the parent's.
• Reuse ThreadLaunchService's workspace preparation, and defer the agent start until the worktree is ready, as launches already do.
• Drop the local refusal from feat(server): delegate_task to a linked environment #16719 (or coordinate with it), so local and linked targets behave the same.

The child keeps everything that makes it a child: parent, completion wake-up, hidden from the sidebar, cancellation with the parent task.

Related: #17401 (sidebar filter by who started a thread) covers the other half of this workflow: the orchestrator's top-level launches crowd the sidebar today.

Happy to send a PR if the direction is agreeable.