Poetry package listing fails for nested/non-root pyproject.toml projects (`poetry show` runs with wrong cwd)

### Environment
- vscode-python-envs version: 1.36.0
- OS: Linux (devcontainer, linux-arm64)
- Poetry: 2.4.3

### Description
When a Poetry project is registered via `python-envs.pythonProjects` but is **not** at the workspace root (e.g. a monorepo with `scripts/pyproject.toml`), the "Manage Packages" package listing fails with:

```
poetry: Poetry could not find a pyproject.toml file in or its parents
```

### Root cause (found in source)
`PoetryPackageManager.getDirectPackageNames()` (`src/managers/poetry/poetryPackageManager.ts`) builds `PoetryShowTopLevelCommand` without ever passing a `cwd`:

```ts
const showTopLevelCmd = new PoetryShowTopLevelCommand({
pythonExecutable: poetry,
log: this.log,
});
```

This means `poetry show --no-ansi --top-level` always inherits the extension host process's own cwd (in a remote/devcontainer setup this is the vscode-server install directory), not the project directory. This is confirmed intentional by the existing unit test `poetryPackageManager.unit.test.ts`: *"direct package listing inherits the process working directory"* asserts `runPoetryStub.firstCall.args[1] === undefined`.

`fetchPackagesFromTool()` (used for plain `poetry show --no-ansi`) does compute a cwd via `getPoetryCwd()`, but that logic only reliably resolves when `api.getPythonProjects()` returns exactly one project. Since VS Code always implicitly adds the workspace root as a project (`PythonProjectManagerImpl.getInitialProjects()`), any repo with a registered non-root Poetry project (e.g. `scripts/`) ends up with 2+ projects, forcing the "match by environment identity" branch — which can return an empty `matchingDirectories` set (and thus `undefined` cwd) depending on how the workspace-root's own resolved environment compares.

### Repro
1. Monorepo with `pyproject.toml` only in a subfolder, e.g. `scripts/pyproject.toml`.
2. Add to `.vscode/settings.json`:
```json
"python-envs.pythonProjects": [
{ "path": "scripts", "envManager": "ms-python.python:poetry", "packageManager": "ms-python.python:poetry" }
]
```
3. Open "Manage Packages" for the `scripts` project's Poetry environment.

### Expected
`poetry show` commands run with cwd set to the registered project directory (`scripts/`).

### Actual
Both `poetry show --no-ansi --top-level` and `poetry show --no-ansi` fail with "could not find a pyproject.toml", repeating every time `packageWatchers` triggers an auto-refresh.

### Suggested fix
- Pass `cwd` (resolved from the project associated with `environment`, e.g. via `api.getPythonProject(environment.environmentPath)` or similar) into `PoetryShowTopLevelCommand` in `getDirectPackageNames()`.
- In `getPoetryCwd()`, prefer resolving cwd from the actual project that owns the environment (e.g. via reverse lookup by environment path) rather than only matching by `envId.id` equality across all projects.

Bắt đầu trong src/managers/poetry/poetryPackageManager.ts, đặc biệt là getDirectPackageNames() và getPoetryCwd(), sau đó đọc poetryPackageManager.unit.test.ts cùng assertion hiện có về thư mục làm việc của process. Theo dõi cách project đã đăng ký và environment được resolve cho các project lồng nhau. Hoàn thành khi cả hai lệnh poetry show đều sử dụng thư mục của project đã đăng ký và các unit test bao phủ hành vi cwd đó.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.