fix: preserve subdirectory position on wt remove

[worktrunk-bot]

Problem

When switching worktrees, wt preserves the user's subdirectory position — if you're in apps/gateway/ and switch, you land in apps/gateway/ of the target worktree (implemented for #937). wt remove did not: it always landed at the destination worktree root, so a user working deep in a monorepo sub-tree had to manually cd back after every removal.

Reported in #3343.

Root cause

prepare_remove_directory_change in src/output/handlers.rs unconditionally cd'd to the destination worktree root (main_path), ignoring the user's position within the worktree being removed. Switch, by contrast, routes its cd through resolve_subdir_in_target, which maps the relative subpath onto the target.

Solution

Reuse the existing resolve_subdir_in_target helper in the remove path. Because prepare_remove_directory_change runs before the git removal, the current directory still exists inside the worktree being removed, so std::env::current_dir() yields the actual sub-position. When the equivalent subdirectory exists in the destination it becomes the cd target; otherwise it falls back to the root (and to the root if the cwd can't be read). The check on the destination is read-only (is_dir()), so there's no data-safety impact.

wt merge lands via the same handler, so it gains the same subdirectory preservation — a consistency win with switch.

This mirrors the always-on behavior chosen for switch in #937 (no new flag/config), keeping the two commands consistent.

Testing

Added two integration tests in tests/integration_tests/directives.rs, alongside the existing switch subdir tests:

• test_remove_preserves_subdir — removing from feature/apps/gateway/ when main/apps/gateway/ exists lands the cd directive in main/apps/gateway/. Fails before the fix (lands at main/), passes after.
• test_remove_falls_back_to_root_when_subdir_missing — when the subdir is absent in the destination, the cd directive lands at the main worktree root.

Verified the reproduction test fails on the unfixed code and passes with the fix. The directives::, remove::, and merge:: integration modules all pass (262 tests).

---

Closes #3343 — automated triage

[worktrunk-bot]

Reviewed as a self-authored triage PR (reviewer role). The fix cleanly reuses the existing resolve_subdir_in_target helper rather than reimplementing the subpath mapping, mirrors the wt switch behavior it's modeled on, and is covered by two integration tests (subdir-present and fallback-to-root). An independent correctness pass over the cd-target computation — including the cwd == worktree root, subdir, and bare-repo (main_path == current_path) edges — surfaced nothing: the resolved target is always under main_path (the destination worktree, distinct from the removed one), and the destination check is read-only (is_dir()), so there's no new deletion behavior.

Flagging for a human look per the repo's data-loss review policy (review-pr.md): this edits src/output/handlers.rs, which lives on the wt remove surface. The change runs before the git removal and only computes where the shell cds to afterward, so it doesn't touch the removal path itself — but a change on that file is maintainer's-eyes-only by policy. @max-sixty, a quick sanity check when you have a moment.

[max-sixty]

great! can we consider unifying these functions so, for example, we get the same behavior with wt merge — basically anything switching paths?

[worktrunk-bot]

Good call. I traced every site that emits a shell cd to move between worktrees:

Command	Subdir helper
wt switch / switch --create	resolve_subdir_in_target ✅
wt remove / wt merge	resolve_subdir_in_target ✅
wt step relocate	hand-rolled dest.join(relative) ❌

So wt merge is actually already covered — it lands via the same handler as wt remove, so this PR gave it subdir preservation for free. The one path still hand-rolling its own logic was wt step relocate.

Unified it in #3346: relocate now routes through the same resolve_subdir_in_target helper (keeping its "only cd if you're inside the moving worktree" guard), which also picks up the helper's symlink canonicalization that the hand-rolled version lacked.