DX: EnterWorktree nests worktrees inside the repo (.claude/worktrees/), causing editor/tooling friction

Problem
The EnterWorktree tool creates worktrees under .claude/worktrees/ inside the main repo's own working tree, and that path is gitignored to keep it out of Git's view. This nested-inside-the-repo layout causes real friction:

• Editors (VS Code confirmed) don't reliably surface the worktree folder in the Explorer/file tree, even when nested inside the currently open workspace — likely due to files.exclude-style hiding or Explorer not picking up dynamically-created subfolders.
• Any tooling that scans "the repo directory" (linters, search indexes, file watchers, CI globbing) has to be specifically told to skip a live secondary checkout sitting inside itself.
• It implies a parent/child relationship between the main checkout and the worktree that doesn't actually exist at the Git level — a worktree is a peer of the main checkout (both point at the same .git object database), not a child of it. Nesting on disk fights that mental model instead of reflecting it.

Normal practice
Worktrees are conventionally placed as sibling directories outside the repo root (e.g. ~/code/myproject/ + ~/code/myproject-feature-a/, or a dedicated ~/code/myproject/worktrees/ parent), not nested inside the repo they're a worktree of. This avoids needing any gitignore entry at all and plays nicely with editors and other repo-scanning tooling by default.

Ask
Consider changing EnterWorktree's default worktree location to a sibling path outside the repo's working tree, rather than .claude/worktrees/ inside it.

Also worth addressing in this ticket: CLAUDE.md files should be updated to reflect this — several project CLAUDE.md files and the global CLAUDE.md currently reference or assume the .claude/worktrees/ convention (worktree-related guidance, git command workarounds for worktrees, etc.), and those would need auditing/updating if the default location changes, so they don't give stale or contradictory instructions to future sessions.