[FEATURE] --worktree / EnterWorktree should respect git submodule boundaries

Problem

When using --worktree or EnterWorktree from within a git submodule directory, the worktree is created for the outermost parent repository rather than the submodule's own repository. This makes native worktree features unusable in multi-submodule workspaces.

Steps to Reproduce

# 1. Create a repo with a submodule
mkdir parent && cd parent && git init
git submodule add https://github.com/some/repo.git my-submodule

# 2. cd into the submodule (which is its own git repo)
cd my-submodule
git rev-parse --show-toplevel  # Returns: /path/to/parent/my-submodule (correct)

# 3. Use EnterWorktree or start with --worktree
claude -w my-feature

Expected Behavior

• The worktree should be created from the submodule's repository (since git rev-parse --show-toplevel from within a submodule returns the submodule root)
• The worktree should contain the submodule's files and history
• The base branch should be from the submodule's remote, not the parent's

Actual Behavior

• The worktree is created from the outermost parent repository
• The worktree is placed at <parent-repo>/.claude/worktrees/<name>/, not relative to the submodule
• The worktree contains the parent repo's files
• The base branch is from the parent repo's origin/main (see also #27134)
• Submodules within the worktree are not initialized
• The .claude/ directory in the worktree comes from the checked-out commit and may be stale

Why This Matters

Multi-submodule workspaces are a common pattern for teams where each submodule is an independent codebase (different languages, different CI, different teams). The parent repo serves as a shared container for configuration, tooling, and cross-project coordination. Key benefits of this pattern:

• Cross-project data lineage: In data engineering, submodules represent stages of a pipeline (e.g., ingestion, transformation, modeling). Having them in one workspace lets you trace lineage across projects by referencing files across submodules — e.g., verifying that a dbt model's output columns match a downstream ML job's expected input.

• Isolated virtual environments: Each submodule can have its own venv with pinned dependencies, while the parent repo provides shared tooling. Developers switch between projects by activating the appropriate venv. This is especially important when submodules have conflicting dependency trees (e.g., one project needs numpy 1.x, another needs numpy 2.x).

• Centralized configuration: The parent repo holds shared config (.claude/, .devcontainer/, environment files, MCP servers) while each submodule owns its own code. This means you configure Claude Code, dev containers, and tooling once, and it applies across all submodules.

Without submodule-aware worktree support, --worktree and EnterWorktree create worktrees of the parent container repo (which has no meaningful code), rather than the submodule where the actual development happens.

Suggested Behavior

When cwd is inside a git submodule:

1. Detect that the current git repo (via git rev-parse --show-toplevel) differs from the project root
2. Create the worktree from the submodule's repository
3. Place the worktree relative to the submodule (e.g., as a sibling directory, or under the submodule's own .claude/worktrees/)
4. Use the submodule's HEAD or default branch as the base (per the fix for #27134)

When cwd is in the parent repo (not inside a submodule), behavior remains unchanged.

Related Issues

• #27134 — EnterWorktree creates from default branch instead of HEAD (same root cause: worktree creation doesn't respect current git context)
• #7852 — Submodule path support for tools
• #14473 — Multi-project workspace discovery
• #2180 — Worktree navigation within project boundaries (closed)

Environment

• Claude Code v2.1.49
• Tested in a devcontainer with 3 git submodules
• Platform: linux (devcontainer)