Edit tool's cross-worktree guard is stricter than the Bash sandbox on the same path

Summary

Working across multiple git worktrees of the same repo (a common setup when running several concurrent Claude Code sessions, one per worktree), the Edit tool unconditionally refuses to write outside the current session's own worktree: "This session is running in an isolated git worktree at X, but Y belongs to a different worktree." Bash, with the sandbox disabled, has no equivalent restriction on that same path — so a legitimate task like resolving a merge conflict in another agent's branch forces every single file edit in that other worktree through Bash + a heredoc instead of the Edit tool.

Impact

Slower and more error-prone than using Edit directly, and inconsistent: two tools enforce different policies for the identical filesystem path, and there's no override for Edit the way dangerouslyDisableSandbox exists for Bash.

Reproduction

1. Have two git worktrees of the same repo checked out locally, in a session created for worktree A.
2. Attempt to use the Edit tool on a file that lives in worktree B.
3. Observe the "belongs to a different worktree" refusal.
4. Attempt the same file write via Bash with dangerouslyDisableSandbox: true — it succeeds with no equivalent restriction.

Suggested fix

Either give Edit the same explicit-override path Bash already has (so a session can deliberately opt into writing to a path outside its own worktree when it genuinely needs to), or make the two tools consistent by default so one doesn't silently block what the other allows.