Worktrees are nightmare, should be disabled by default

### Describe the bug

Worktrees must be disabled by default, and enabled only by human user! Right now I found myself in a situation when a session was handed to CLI, and ended up with thousands of new lines of _useful_ code, but impossible to apply back to main worktree for whatever git-related reason.

Applying complex subtree patches with AI-generated code causes immeasurable suffering, as there is no reliable merge UI inside VSCode, and whenever worktree fails to merge, user is stuck with hairy git command line options or lottery-like AI-driven resolution, which can render whole branch broken (if you were careful enough to branch out before starting a session):

What am I as user supposed to do here??

Git output from VSCode:
```
.git/copilot/worktree-2026-03-24T01-13-39.patch:4471: trailing whitespace.
**Amended:** 2026-03-23 — hostnames confirmed
error: .github/prompts/continue-autonomous-implementation.prompt.md: already exists in working directory
error: patch failed: ./.adonisjs/server/controllers.ts:8
error: ./.adonisjs/server/controllers.ts: patch does not apply
error: patch failed: ./.adonisjs/server/pages.d.ts:18
error: ./.adonisjs/server/pages.d.ts: patch does not apply
error: patch failed: ./app/middleware/auth_middleware.ts:30
error: ./app/middleware/auth_middleware.ts: patch does not apply
error: ./inertia/composables/use_supabase_auth_legacy.ts: already exists in working directory
error: patch failed: ./inertia/locales/en.ts:1193
error: ./inertia/locales/en.ts: patch does not apply
error: patch failed: ./inertia/locales/ja.ts:1174
error: ./inertia/locales/ja.ts: patch does not apply
error: patch failed: ./inertia/locales/ru.ts:1210
error: ./inertia/locales/ru.ts: patch does not apply
error: patch failed: ./inertia/locales/th.ts:1168
error: ./inertia/locales/th.ts: patch does not apply
error: patch failed: ./inertia/locales/zh.ts:1117
[... goes on for every file modified in the worktree...]
```

To be clear, the main worktree is clean, nothing to commit, yet all these conflicts from the worktree that was spawned just couple hours ago... Speaking as a git user with years of experience, this is really baffling and totally uninvited behaviour.

### Affected version

v1.0.11

### Steps to reproduce the behavior

Start a session in Copilot chat, handover to CLI, get tied in a 'apply worktree changes' knot.

### Expected behavior

No worktrees unless user enables them

Start by tracing the Copilot Chat handover to CLI flow and the code that creates or applies Git worktrees; the issue does not name specific files or entry points. Reproduce the handover scenario on v1.0.11, then verify that a worktree is not created unless the user explicitly enables it and that the existing opt-in path still works.

Written by the indexing model from the issue text.