`create_terminal_task` and `create_terminal_shell_internal` previously
built their toolchain candidate list as `[active_editor_entry.path,
...visible_worktrees]` and used the first one with a persisted
toolchain. A Python toolchain persisted for worktree A would leak into a
terminal opened in worktree B of the same window: with a conda env
selected for one project, every terminal in every other project of the
window inherited that env's activation at startup.

This scopes the candidate list to the worktree that contains the
terminal's CWD. Both call sites now derive candidates from
`find_worktree(path)`, where `path` is the terminal's resolved CWD
(`spawn_task.cwd` or `active_project_directory`). If the path lives in a
worktree, lookup runs scoped to that worktree's id. If not, no toolchain
is applied.

## Design decision

The previous fallback chain (active editor's worktree, then all visible
worktrees) is removed entirely. Both fallbacks were sources of the leak:

- "Active editor's worktree" is order-dependent: opening a terminal in
worktree B picks up worktree A's toolchain because a file in A is
focused.
- "All visible worktrees" is worse, since the first worktree with any
persisted toolchain wins.

Workflows that relied on either fallback need to set the toolchain
explicitly on the worktree where the terminal is opened.

## Coverage

`cargo check -p project` is clean. There is no unit test for the
cross-worktree case; that would require a multi-worktree Project fixture
with persisted toolchains, which doesn't exist in the test suite today.
Reproduction is straightforward: open a workspace with two folders,
select a Python toolchain in one, open a terminal in the other, and
observe the leaked activation script in the spawned shell.

Release Notes:

- Fixed Python toolchains persisted for one worktree leaking into
terminals opened in other worktrees of the same workspace.