fix(git): anchor Repository::current_worktree() to discovery path

[max-sixty]

Summary

Repository::current_worktree() resolved against the process-global base_path() (CWD or -C), not against the Repository's own discovery_path. The two coincide for Repository::current() (the common case), but Repository::at(p) callers — output handlers, picker, run_pipeline, tests, recovery — silently got a WorkingTree at the process CWD instead of at p.

PR #2625 patched one symptom inline (infer_default_branch_locally was calling current_worktree().is_linked() and reaching for the wrong path). This change fixes the helper itself, which subsumes that workaround and the sibling sites identified in the audit (Pass B from the structural audit done in PR #2649's session): project_config_path, project_config, require_current_branch, resolve_worktree_name("@"), resolve_worktree("@").

Why structural over per-site

Five sibling sites use self.current_worktree() with the same intent: "operate on the worktree this Repository represents." Patching each individually would leave the helper as a footgun — the next sibling added would re-introduce the bug. Fixing current_worktree() itself matches what its name has always promised. Audited production callers; none rely on the old "use process CWD even though self was constructed elsewhere" semantics.

What's in this diff

• src/git/repository/mod.rs: current_worktree() → worktree_at(self.discovery_path.clone()). Docstring explains the dual semantics.
• src/git/repository/config.rs: revert PR fix(git): tolerate non-git paths in WorkingTree::is_linked #2625's per-method workaround (now redundant).
• src/git/repository/working_tree.rs: update WorkingTree::path docstring that referenced base_path().
• src/git/repository/tests.rs: regression test pins both directions — matches discovery_path(), not process CWD.
• src/commands/worktree/switch.rs: gate the source-worktree capture on !is_recovered. Without this, current_worktree() in recovery mode would resolve to the recovered ancestor (typically the main worktree) and expand {{ base }} / {{ base_worktree_path }} to main's identity instead of empty strings. Mirrors the existing !is_recovered gate on pre-switch hooks at line 1264. Caught by code review.
• tests/integration_tests/repository.rs: remove three stale "use worktree_at, not current_worktree() which uses base_path()" comments.

Test plan

• All 1740 unit tests pass
• Full integration suite (1632 tests) passes
• PR fix(git): tolerate non-git paths in WorkingTree::is_linked #2625's two regression tests still pass (the structural fix preserves the original bug-fix's behavior)
• pre-commit run --all-files clean

🤖 Generated with Claude Code

[worktrunk-bot]

Structural fix is well-motivated — the docstring update on current_worktree() makes the dual semantics explicit, and the regression test pins down both directions (matches discovery path, not process CWD). The is_recovered gate in switch.rs is the right call: before this PR the empty source_branch/source_path came from current_worktree().root() failing on the deleted CWD; after the fix, those calls would resolve to the recovered ancestor and silently report main's identity as the user's "base".

One stale comment outside the diff worth a follow-up touch:

src/commands/worktree/switch.rs:1355-1356

// When recovered from a deleted worktree, current_dir() and current_worktree().root()
// both fail — fall back to repo_path() (the main worktree root).

After this PR's structural fix, current_worktree().root() no longer fails in recovery — it resolves to the recovered ancestor (the main worktree, since recover_from_path only returns repos with a .git directory), which is the same path repo_path() returns. Behavior is preserved, but the comment now misleads. Suggested rewording:

// When recovered from a deleted worktree, current_dir() fails — fall back to
// repo_path() (the main worktree root).

Happy to push the touch-up if you'd like.

[worktrunk-bot]

CI on linux/macos/windows is failing for a real regression introduced by this PR — the new docstring on current_worktree() adds an intra-doc link to [`Repository::at(p)`], which rustdoc can't resolve (the (p) argument list isn't valid in a path expression). With RUSTDOCFLAGS='-Dwarnings', this fails the doc step in wt hook pre-merge:

error: unresolved link to `Repository::at(p)`
   --> src/git/repository/mod.rs:898:24
    |
898 |     /// meaning. For [`Repository::at(p)`] the discovery path is `p`, and this
    |                        ^^^^^^^^^^^^^^^^^ the struct `Repository` has no field or associated item named `at(p)`

Mechanical fix — drop the (p) from the link target (the p is still introduced as a code-span on the same line). Inline suggestion below.

---

codecov/patch also flags the is_recovered = true arm at src/commands/worktree/switch.rs:1302 ((String::new(), String::new())) as uncovered. The test_remove_current_worktree_fires_post_switch_hook test exercises recovery but the implicit switch-back doesn't appear to flow through run_switch's new branch, so the empty-string contract isn't pinned down. A targeted test asserting that {{ base }} and {{ base_worktree_path }} expand to empty strings in a recovered switch would both close the codecov gap and serve as a regression guard for the gate. Happy to push both fixes if you'd prefer not to do them yourself.

CI failed — rustdoc broken intra-doc link in new docstring (and codecov gap on the is_recovered branch). See follow-up review.