Copilot Agent: In create_session with worktree: true allow to set the base branch

Each time it creates a new worktree from main branch only, I would like agent to have a option to define the base branch from there the worktree should be created

for now I'm using this workaround prompt:

```
Call `create_session` with `relationship: "independent"` and `worktree: true` to create a worktree session for each implementer subagent, using this exact prompt and always keeping `/implement` in it:

Rebase this branch onto , then /implement #.
On completion, send exactly "# implemented on ." to using send_message.

Here, `` is the latest commit after the most recent merge-agent commit, if one exists.
```

> And one more thing you can see in this prompt that I mentioned to rebase the worktree, because it always creates new worktree from the main branch, but I would like a option to create a worktree from a specific branch or commit hash.
>
> I'm sharing my skill here, it is Matt Pocock implement-spec skill, that I have updated to use it with copilot.
>
> ```
> ---
> name: implement-spec
> description: "Implement a specification in code."
> ---
>
> You have been provided a spec. This spec should have tickets associated with it, describing how to implement the spec.
>
> The goal is a PR which implements the entire spec on a single branch.
>
> The tickets are not a list of steps. They are a **task graph** with blocking relationships between them. This means there is always a **frontier** of tickets which are ready to be grabbed.
>
> Communication to and from subagents should be sparse. Communicate primarily through **context pointers**: to the spec, tickets, research notes, and previous commits. Don't duplicate information already available via pointers.
>
> **Implementer subagents** should be run in the background where possible for **maximum concurrency**.
>
> After dispatching work, **end the turn** and resume only when a child sends its completion message.
>
> ## Steps
>
> 1. Read the spec and tickets. Read enough to understand the task graph.
>
> 2. (optional) Use an **exploration subagent** to conduct any exploration required by the tickets - relevant codebase files or external documentation. Ensure the exploration subagent can save files - it should save its markdown notes in a directory outside the repo, accessible by all future subagents. This lets **implementer subagents** focus on implementation rather than exploration.
>
> 3. Create a branch, and a draft PR. The PR should be marked as 'closing' the spec issue and tickets.
>
> 4. Use **implementer subagents** to implement each ticket. Each implementer subagent should work in its own worktree, on its own branch.
>
> 5. Once an **implementer subagent** completes, merge its work to the PR branch with a **merger subagent**.
>
> 6. If this changes the **frontier** of available tickets, kick off more **implementer subagents** to work on the new tickets. This allows for maximum concurrency.
>
> 7. Once all tickets are complete, run /code-review on the PR branch. Fix all issues raised by the code review in a single **implementer subagent**.
>
> 8. Mark the PR as ready for review.
>
> ## Implementer Subagent
>
> Call `create_session` with `relationship: "independent"` and `worktree: true` to create a worktree session for each implementer subagent, using this exact prompt and always keeping `/implement` in it:
>
> Rebase this branch onto , then /implement #.
> On completion, send exactly "# implemented on ." to using send_message.
>
> Here, `` is the latest commit after the most recent merge-agent commit, if one exists.
>
> ## Merger Subagent
>
> Create the first merge chat with `create_session` and `relationship: "currentSession"`, then reuse it with `send_message` for subsequent merges, always using this exact prompt:
>
> /merge into in this chat's current worktree as one commit named "Closes #: "
> On completion, send exactly "# merged." to this session's default chat using send_message.
>
> ## PR
>
> Do not create a draft PR in step 3. Create a ready-for-review PR in step 8 and mark it as closing the spec issue. Do not list tickets in the PR description.
> ```

_Originally posted by @MominRaza in [#335069](https://github.com/microsoft/vscode/issues/335069#issuecomment-5637216356)_